From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DvTj6-0004Jg-W7 for garchives@archives.gentoo.org; Thu, 21 Jul 2005 05:36:09 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6L5Z4Ks013152; Thu, 21 Jul 2005 05:35:04 GMT Received: from smtp111.mail.sc5.yahoo.com (smtp111.mail.sc5.yahoo.com [66.163.170.9]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6L5UMok013393 for ; Thu, 21 Jul 2005 05:30:23 GMT Received: (qmail 9558 invoked from network); 21 Jul 2005 05:30:36 -0000 Received: from unknown (HELO ?192.168.50.105?) (richard?j?fish@212.180.33.26 with plain) by smtp111.mail.sc5.yahoo.com with SMTP; 21 Jul 2005 05:30:36 -0000 Message-ID: <42DF33AC.9090209@asmallpond.org> Date: Thu, 21 Jul 2005 07:33:32 +0200 From: Richard Fish User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050715) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gzip segmentation fault References: <200507191634.39879.elinar@ihug.co.nz> <200507202228.14489.elinar@ihug.co.nz> <42DE853F.7090604@gmail.com> <200507210954.35076.elinar@ihug.co.nz> In-Reply-To: <200507210954.35076.elinar@ihug.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 97fd62b9-9b5c-4c6c-9cd7-2a62e126a92d X-Archives-Hash: b55040e3c758e8b06d39b49ebc8fb988 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