[gentoo-user] gzip segmentation fault

[gentoo-user] gzip segmentation fault

[Glenn Enright]

gzip seg faults when uncompressing. Man and info pages work fine as do 
emerges, and after recompiling zlib, glibc and some other stuff, I still have 
no clue what the problem is.

Before you ask I'm not running ypbind, and have a P4 2.6. Any ideas peoples?
-- 

SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS

	Bart Simpson on chalkboard in episode BABF09
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> gzip seg faults when uncompressing. Man and info pages work fine as do 
> emerges, and after recompiling zlib, glibc and some other stuff, I still have 
> no clue what the problem is.
> 
> Before you ask I'm not running ypbind, and have a P4 2.6. Any ideas peoples?

That could be a hardware problem.  Maybe your cpu is overheating or there's something wrong with your ram.  You can use a livecd with memtest86+ to test the ram.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Tue, 19 Jul 2005 16:56, Zac Medico wrote:
> Glenn Enright wrote:
> > gzip seg faults when uncompressing. Man and info pages work fine as do
> > emerges, and after recompiling zlib, glibc and some other stuff, I still
> > have no clue what the problem is.
> >
> > Before you ask I'm not running ypbind, and have a P4 2.6. Any ideas
> > peoples?
>
> That could be a hardware problem.  Maybe your cpu is overheating or there's
> something wrong with your ram.  You can use a livecd with memtest86+ to
> test the ram.
>
> Zac

Seems odd considering I am able to do major emerges with no apparent errors, 
including glibc, mplayer, etc. Still its worth checking out, so will give it 
a go tonight.

-- 

To talk little is natural.
High winds do not last all morning.
Heavy rain does not last all day.
Why is this?  Heaven and Earth!
If heaven and Earth cannot make things eternal,
How is it possible for man?
He who follows the Tao
Is at one with the Tao.
He who is virtuous
Experiences Virtue.
He who loses the way
Is lost.
When you are at one with the Tao,
The Tao welcomes you.
When you are at one with Virtue,
The Virtue is always there.
When you are at one with loss,
The loss is experienced willingly.

He who does not trust enough
Will not be trusted.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Wed, 20 Jul 2005 00:32, Glenn Enright wrote:
> On Tue, 19 Jul 2005 16:56, Zac Medico wrote:
> > That could be a hardware problem.  Maybe your cpu is overheating or
> > there's something wrong with your ram.  You can use a livecd with
> > memtest86+ to test the ram.
> >
> > Zac
>
> Seems odd considering I am able to do major emerges with no apparent
> errors, including glibc, mplayer, etc. Still its worth checking out, so
> will give it a go tonight.
>
Ok memtest been running for a few hours, but gave up nothing. stranger and 
stranger... might try a ~x86 version
-- 

M: co je ten QNX momentics? 
F: Poznas Mochovce?
M: to potrebuje na chod celu atomovku?
   to mi ten zdroj neutiahne :-PPP
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> On Wed, 20 Jul 2005 00:32, Glenn Enright wrote:
> 
>>On Tue, 19 Jul 2005 16:56, Zac Medico wrote:
>>
>>>That could be a hardware problem.  Maybe your cpu is overheating or
>>>there's something wrong with your ram.  You can use a livecd with
>>>memtest86+ to test the ram.
>>>
>>>Zac
>>
>>Seems odd considering I am able to do major emerges with no apparent
>>errors, including glibc, mplayer, etc. Still its worth checking out, so
>>will give it a go tonight.
>>
> 
> Ok memtest been running for a few hours, but gave up nothing. stranger and 
> stranger... might try a ~x86 version

You're not using any abnormal CFLAGS, are you?

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Wed, 20 Jul 2005 19:33, Zac Medico wrote:
> Glenn Enright wrote:
> > On Wed, 20 Jul 2005 00:32, Glenn Enright wrote:
> >>On Tue, 19 Jul 2005 16:56, Zac Medico wrote:
> >>>That could be a hardware problem.  Maybe your cpu is overheating or
> >>>there's something wrong with your ram.  You can use a livecd with
> >>>memtest86+ to test the ram.
> >>>
> >>>Zac
> >>
> >>Seems odd considering I am able to do major emerges with no apparent
> >>errors, including glibc, mplayer, etc. Still its worth checking out, so
> >>will give it a go tonight.
> >
> > Ok memtest been running for a few hours, but gave up nothing. stranger
> > and stranger... might try a ~x86 version
>
> You're not using any abnormal CFLAGS, are you?
>
> Zac

Not that I wouldve picked, trying with some basic ones now. It would seem that 
because emerge is still working, that the problems are from when I *make* gz 
files, rather than outside files from such as portage. The files I make unzip 
to a zero length file and deliver a seg fault. Hmm...
-- 

A computer without Windows is like a fish without a bicycle
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> 
> Not that I wouldve picked, trying with some basic ones now. It would seem that 
> because emerge is still working, that the problems are from when I *make* gz 
> files, rather than outside files from such as portage. The files I make unzip 
> to a zero length file and deliver a seg fault. Hmm...

Well, gzip and zlib are two separate packages.  Did you remerge both?  Also you can compare with busybox gzip.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Wed, 20 Jul 2005 19:33, Zac Medico wrote:
> Glenn Enright wrote:
> > On Wed, 20 Jul 2005 00:32, Glenn Enright wrote:
> >>On Tue, 19 Jul 2005 16:56, Zac Medico wrote:
> >>>That could be a hardware problem.  Maybe your cpu is overheating or
> >>>there's something wrong with your ram.  You can use a livecd with
> >>>memtest86+ to test the ram.
> >>>
> >>>Zac
> >>
> >>Seems odd considering I am able to do major emerges with no apparent
> >>errors, including glibc, mplayer, etc. Still its worth checking out, so
> >>will give it a go tonight.
> >
> > Ok memtest been running for a few hours, but gave up nothing. stranger
> > and stranger... might try a ~x86 version
>
> You're not using any abnormal CFLAGS, are you?
>
> Zac

Ok did this
CFLAGS="-pipe -march=pentium4 -O2" emerge -avD zlib gzip

and still getting the same errors. normal CFLAGS are as follows
CFLAGS="-pipe -w -march=pentium4 -O2 -mfpmath=sse -fomit-frame-pointer -fweb"

-- 

fortune: No such file or directory
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> 
> Ok did this
> CFLAGS="-pipe -march=pentium4 -O2" emerge -avD zlib gzip
> 
> and still getting the same errors. normal CFLAGS are as follows
> CFLAGS="-pipe -w -march=pentium4 -O2 -mfpmath=sse -fomit-frame-pointer -fweb"
> 

Does busybox gzip work any better?

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

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?

-- 

Seeing is believing.  You wouldn't have seen it if you hadn't believed it.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

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
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

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 +++


-- 

There are times when truth is stranger than fiction and lunch time is one
of them.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> 
> 
> 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...

My system is mostly ~x86 stuff and I've never had a problem like yours.  I currently use glibc-2.3.5 and gcc-3.4.3-r1 with no noticeable troubles.

I was going to suggest that you check the digests on glibc with "equery check glibc" but looking back at the original email I see that you already rebuilt it.  It looks like you definitely need to look at the toolchain (things listed in "emerge --info" like binutils and gcc).

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Thu, 21 Jul 2005 10:02, Zac Medico wrote:
> Glenn Enright wrote:
> > 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...
>
> My system is mostly ~x86 stuff and I've never had a problem like yours.  I
> currently use glibc-2.3.5 and gcc-3.4.3-r1 with no noticeable troubles.
>
> I was going to suggest that you check the digests on glibc with "equery
> check glibc" but looking back at the original email I see that you already
> rebuilt it.  It looks like you definitely need to look at the toolchain
> (things listed in "emerge --info" like binutils and gcc).
>
> Zac

ok thanks heaps for all your help. back to the drawing board...
-- 

===  ALL CSH USERS PLEASE NOTE  ========================

Set the variable $LOSERS to all the people that you think are losers.  This
will cause all said losers to have the variable $PEOPLE-WHO-THINK-I-AM-A-LOSER
updated in their .login file.  Should you attempt to execute a job on a 
machine with poor response time and a machine on your local net is currently
populated by losers, that machine will be freed up for your job through a
cold boot process.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Richard Fish]

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

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Richard Fish wrote:
> I will take a look through the gzip source and see if anything interesting shows up.  

Richard, you are a saint ;-).  But remember, he said that gunzip only segfaults with files that he compressed himself which suggests that the files are being corrupted when he compresses them.  You'd thing that gunzip would be able to handle the corruption better that segfaulting though.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Thu, 21 Jul 2005 17:45, Zac Medico wrote:
> Richard Fish wrote:
> > I will take a look through the gzip source and see if anything
> > interesting shows up.
>
> Richard, you are a saint ;-).  But remember, he said that gunzip only
> segfaults with files that he compressed himself which suggests that the
> files are being corrupted when he compresses them.  You'd thing that gunzip
> would be able to handle the corruption better that segfaulting though.
>
> Zac

Ok just ran gcc-config and found 
lib # gcc-config -l
/usr/bin/gcc-config: line 
583: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or 
directory
 * /usr/bin/gcc-config: Profile does not exist or invalid setting 
for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110
[1] i686-pc-linux-gnu-3.3.5
[2] i686-pc-linux-gnu-3.3.5-hardened
[3] i686-pc-linux-gnu-3.3.5-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-hardenednossp
[5] i686-pc-linux-gnu-3.4.4
[6] i686-pc-linux-gnu-3.4.4-hardened
[7] i686-pc-linux-gnu-3.4.4-hardenednopie
[8] i686-pc-linux-gnu-3.4.4-hardenednopiessp
[9] i686-pc-linux-gnu-3.4.4-hardenednossp

Thats not right. gonna select 5 and take it through glibc (which was failing 
the 'make test') and gzip, see what happens :P
-- 

On ability:
	A dwarf is small, even if he stands on a mountain top;
	a colossus keeps his height, even if he stands in a well.
		-- Lucius Annaeus Seneca, 4BC - 65AD
e
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Richard Fish]

Glenn Enright wrote:

>On Thu, 21 Jul 2005 17:45, Zac Medico wrote:
>  
>
>>Richard Fish wrote:
>>    
>>
>>>I will take a look through the gzip source and see if anything
>>>interesting shows up.
>>>      
>>>
>>Richard, you are a saint ;-).  But remember, he said that gunzip only
>>segfaults with files that he compressed himself which suggests that the
>>files are being corrupted when he compresses them.  You'd thing that gunzip
>>would be able to handle the corruption better that segfaulting though.
>>
>>Zac
>>    
>>
>
>Ok just ran gcc-config and found 
>lib # gcc-config -l
>/usr/bin/gcc-config: line 
>583: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or 
>directory
> * /usr/bin/gcc-config: Profile does not exist or invalid setting 
>for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110
>[1] i686-pc-linux-gnu-3.3.5
>[2] i686-pc-linux-gnu-3.3.5-hardened
>[3] i686-pc-linux-gnu-3.3.5-hardenednopie
>[4] i686-pc-linux-gnu-3.3.5-hardenednossp
>[5] i686-pc-linux-gnu-3.4.4
>[6] i686-pc-linux-gnu-3.4.4-hardened
>[7] i686-pc-linux-gnu-3.4.4-hardenednopie
>[8] i686-pc-linux-gnu-3.4.4-hardenednopiessp
>[9] i686-pc-linux-gnu-3.4.4-hardenednossp
>
>Thats not right. gonna select 5 and take it through glibc (which was failing 
>the 'make test') and gzip, see what happens :P
>  
>

This seems like a very sane plan.

FYI, regarding the points I made earlier:

The "trampolin" stuff is related to gzip looking to see if the 
filesystem automatically shortened the file name that gzip creates.  I 
didn't analyze it in detail, but it seems to be normal and intended.

Regarding the lstat64 vs stat64, this is more interesting.  It basically 
means that the configure step probably didn't find an lstat call on your 
system.  This suggests to me a problem in your system headers or 
compiler toolchain.

If fixing the gcc-config doesn't produce sane results, what I suggest is 
the following commands:

# cd /usr/local/src
# tar -xzvf /usr/portage/distfiles/gzip-1.3.5.tar.gz
# cd gzip-1.3.5
# ./configure
# grep HAVE_LSTAT config.h

If HAVE_LSTAT is commented out, then create a "testlstat.c" file with 
the following:

char lstat();
int main() {
    char (*f)();
    f = lstat;
    return 0;
}

Compile the above with "gcc -o testlstat testlstat.c".  It should fail 
to compile, and the resulting error should give us a good place to look 
for the real problem.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Glenn Enright]

On Fri, 22 Jul 2005 08:32, Richard Fish wrote:

actually turns out that I had an old version of gzip living in /usr/bin for 
some odd reason. Now that I've removed it and added symlinks to /bin, all my 
problems have gone away! Sorry for all the hassle guys. My system has been 
installed for since 2004.1 with many updates since. Obviously its gotten a 
bit messy :P

-- 

 Marv Albert: He's really showing us what a man with a cannon 
   in his chest can do.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gzip segmentation fault

[Zac Medico]

Glenn Enright wrote:
> On Fri, 22 Jul 2005 08:32, Richard Fish wrote:
> 
> actually turns out that I had an old version of gzip living in /usr/bin for 
> some odd reason. Now that I've removed it and added symlinks to /bin, all my 
> problems have gone away! Sorry for all the hassle guys. My system has been 
> installed for since 2004.1 with many updates since. Obviously its gotten a 
> bit messy :P
> 

That actually crossed my mind and one point but I neglected to mention it.  I meant to ask what the output of "which gzip" was.  Oh well ;-).

Zac
-- 
gentoo-user@gentoo.org mailing list