| 1 |
Am 17.01.2014 18:14, schrieb Daniel Frey: |
| 2 |
> On 01/16/2014 08:07 PM, lovely2 wrote: |
| 3 |
>> I doubt this is a memory problem. I've just had the same problem with |
| 4 |
>> glibc-2.17 and python. I manually went back to glibc-2.16 and everything is |
| 5 |
>> fine again. I then tried re-emerging all the python versions with glibc-2.16 |
| 6 |
>> installed and then re-emerged glibc-2.17 and had the same problem. |
| 7 |
>> |
| 8 |
>> After running strace on the python2.7. My best guess is that it is a kernel |
| 9 |
>> <> glibc-2.17 incompatiblity. The segfault happens near a mprotect |
| 10 |
>> operation, very early on. |
| 11 |
>> |
| 12 |
>> vault ~ # strace python |
| 13 |
>> -- snip -- |
| 14 |
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = |
| 15 |
>> 0xb7462000 |
| 16 |
>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb74626c0, limit:1048575, |
| 17 |
>> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, |
| 18 |
>> seg_not_present:0, useable:1}) = 0 |
| 19 |
>> mprotect(0xb7658000, 8192, PROT_READ) = 0 |
| 20 |
>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- |
| 21 |
>> +++ killed by SIGSEGV +++ |
| 22 |
>> Segmentation fault |
| 23 |
>> |
| 24 |
>> vault ~ # uname -a |
| 25 |
>> Linux vault 2.6.31-gentoo-r10 #1 SMP Sun Mar 7 14:35:15 EST 2010 i686 |
| 26 |
>> Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux |
| 27 |
>> |
| 28 |
>> I'm upgrading to the latest gentoo-sources. Only thing i'm worried about is |
| 29 |
>> rebooting but all in the life of a gentoo user. |
| 30 |
> |
| 31 |
> That could very well be (kernel issue with glibc-2.17.) I just upgraded |
| 32 |
> some 3 year old gentoo VMs and managed to get everything installed. The |
| 33 |
> kernel was the last thing I did have to upgrade, but I was on |
| 34 |
> gentoo-sources-2.6.32 and had no segfault problems. |
| 35 |
> |
| 36 |
> From memory, I had to upgrade things in this order: |
| 37 |
> -run emerge --sync |
| 38 |
> -gcc (then switch to new version) |
| 39 |
> -emerge libtool, binutils, linux-headers, glibc (glib as a dependency |
| 40 |
> had to be masked to build, may have to solve some other blocks like a |
| 41 |
> fallocate64 error, i think i had to use `ac_cv_func_fallocate=no emerge |
| 42 |
> bintuils` so libtool would build?) |
| 43 |
> -rebuild gcc (advise from the gcc package - rebuild after glibc update) |
| 44 |
> -upgrade baselayout and openrc (inc. udev, module-init-tool->kmod, etc) |
| 45 |
> -perl (then run perl-cleaner) |
| 46 |
> -python (then remove all stale versions of 3.x and 2.x, switch active to |
| 47 |
> 2.7) |
| 48 |
> -python-updater |
| 49 |
> -upgrade portage, portage-utils |
| 50 |
> -unmask things I'd individually masked and try to solve blocks emerging |
| 51 |
> world |
| 52 |
> -eventually world would run, make sure everything built |
| 53 |
> -run emerge-pvuDNe to make sure nothing was missed (something always is) |
| 54 |
> then upgrade those packages |
| 55 |
> -run emerge --depclean |
| 56 |
> -run emerge @preserved-rebuild |
| 57 |
> -run python-update & perl-cleaner |
| 58 |
> -run revdep-rebuild |
| 59 |
> -build & install new kernel (in my case 3.10.25) |
| 60 |
> -reboot |
| 61 |
> |
| 62 |
> Damn, it works and it's up to date. Now I wish I could say that only |
| 63 |
> took an hour, but on the first machine it took me almost 10 hours |
| 64 |
> because I was almost always trying to work around blocks. The very last |
| 65 |
> one I got down to 7 hours as I knew exactly what I had to do. |
| 66 |
|
| 67 |
Thanks for your feedback! |
| 68 |
|
| 69 |
I will check back here ... in the next week I will have another old box |
| 70 |
to update, this time from a kernel 2.6.27-gentoo-r8 ... with gcc 4.1.2, |
| 71 |
and udev 124-r2 !! |
| 72 |
|
| 73 |
It was kept in this state to keep good old vmware-player-1.x running. |
| 74 |
Now I deployed a new gentoo-based KVM-server there ... at last! |
| 75 |
|
| 76 |
Stefan |
Archives