Re: [gentoo-user] gzip segmentation fault

[Richard Fish <bigfish@asmallpond.org>]

Glenn Enright wrote:

>On Thu, 21 Jul 2005 05:09, Zac Medico wrote:
>  
>
>>Glenn Enright wrote:
>>    
>>
>>>On Wed, 20 Jul 2005 21:26, Zac Medico wrote:
>>>      
>>>
>>>>Does busybox gzip work any better?
>>>>
>>>>Zac
>>>>        
>>>>
>>>Yes works just fine. What does that tell you?
>>>      
>>>
>>You have a workaround ;-).  The problem seems to be in glibc (only
>>dependency of gzip, verified by "ldd `which gzip`") or your toolchain.  You
>>might be able to get some clues from gdb or strace, but whatever the cause,
>>you probably need to replace glibc and/or your toolchain.
>>
>>I wonder if static linking would help gzip?
>>
>>USE=static emerge gzip
>>
>>Zac
>>    
>>
>
>Bugger. was afraid of that. Ive been running gcc3.4 for a while which needs 
>some ~x86 stuff (glibc). Umm... static doesnt change.
>
>Strace on gzip isnt very interesting, gunzip gives me a stat64 file error 
>towards the end...
>open("trampoline.gz", O_RDONLY|O_LARGEFILE) = 3
>read(3, "\37\213\10\0109\306\336B\0\3trampoline\0\313\316\316\316"..., 32768) 
>= 53
>read(3, "", 32715)                      = 0
>stat64("trampoline", 0xbfffe880)        = -1 ENOENT (No such file or 
>directory)
>open("trampoline", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
>fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
>stat64("trampolin", 0xbfffe880)         = -1 ENOENT (No such file or 
>directory)
>--- SIGSEGV (Segmentation fault) @ 0 (0) ---
>+++ killed by SIGSEGV +++
>  
>

A couple of interesting things.  I compared to what happens on my 
machine, and I get the following:

lstat64("trampoline.gz", {st_mode=S_IFREG|0644, st_size=2277, ...}) = 0
open("trampoline.gz", O_RDONLY|O_LARGEFILE) = 3
read(3, "\37\213\10\10\226-\337B\2\3trampoline\0\255\232[o\343\266"..., 
32768) = 2277
read(3, "", 30491)                      = 0
lstat64("trampoline", 0xbfd7efec)       = -1 ENOENT (No such file or 
directory)
open("trampoline", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat64("trampolin", 0xbfd7ef6c)        = -1 ENOENT (No such file or 
directory)
brk(0)                                  = 0x80a4000
brk(0x80c5000)                          = 0x80c5000
write(4, "USER       PID %CPU %MEM    VSZ "..., 9632) = 9632
close(3)                                = 0
fchmod(4, 0644)                         = 0
fchown32(4, 500, 100)                   = 0
close(4)                                = 0
utime("trampoline", [2005/07/21-07:07:34, 2005/07/21-07:07:34]) = 0
unlink("trampoline.gz")                 = 0

First, my system is using "lstat64" to test files, not "stat64".  Second 
is that I get a couple of brk calls that are missing from your trace. 

Is this with the static build?  Could you try again with the dynamic 
build and see what changes?

When I get back to my hotel tonight (currently in Europe) I will take a 
look through the gzip source and see if anything interesting shows up.  
In particular, I want to know why gunzip is even looking for a file 
named "trampolin".

Oh, and for the record, my system is ~x86, gcc 3.4.4, P4 with:

CFLAGS="-march=pentium4 -Os -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
carcharias rjf # emerge -Dv --pretend app-arch/gzip sys-libs/glibc
[ebuild   R   ] app-arch/gzip-1.3.5-r8  -build +nls +pic -static 0 kB
[ebuild   R   ] sys-libs/glibc-2.3.5  -build -debug -erandom -hardened 
(-multilib) +nls +nptl +nptlonly +pic (-selinux) -userlocales 18 kB

One last thing, the brk calls are related to resource limits.  So check 
"ulimit -a", and make sure that "data seg size" and "max memory size" 
are both unlimited.

-Richard

-- 
gentoo-user@gentoo.org mailing list