This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: boehm-gc test failure on sparc-linux


> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> 
> On Tue, Feb 12, 2002 at 02:04:11PM -0800, Boehm, Hans wrote:
> > It's at least a little clearer what's going on here.  But I 
> think we're
> > still not making a lot of progress.  My guess is that you 
> have a severaly
> > broken gdb (or maybe a broken ptrace in the kernel).  You 
> really need to get
> > that fixed first.
> 
> hmm, perhaps debian's gdb is broken, but that won't explain gc
> failure, right?
It doesn't.  But it makes it far harder to debug.  It might be good to check
whether the frame pointer is always wrong, e.g. by stopping it in a "hello
world" program, looking at some locals, and at "info registers".  The frame
pointer and stack pointer should be close.  If that also fails, you have a
simple test to send to the Debian developers.
> 
> > The state at the initial SIGSEGV should not be interesting. 
>  That fault is
> > intentional, and it's just determining where statically 
> allocated variables
> > are allocated.
> 
> Is this the case when running the boehm-gc test in the gcc source tree
> also? (Then, IMHO, it's something wrong with the setup of that
> gctest...)
I believe so.  It shouldn't be an issue, since the SIGSEGV is caught.  You
won't notice it unlesss you're debugging.  I suspect the problem there also
is a second SIGSEGV.
> 
> > At the second fault, the %fp (frame pointer) register 
> appears to contain
> > something that's nowhere near the stack pointer (%sp).  
> That's wrong, since
> > it should point to the previous stack frame.  This in turn 
> explains why gdb
> > can't print values of local variables or parameters; it 
> would normally find
> > those by starting with the frame pointer.
> 
> Now, this shouldn't be a gdb failure, right? It's just a register
> dump, can't be too erroneously implemented but we never know...
It doesn't look plausible to me.  It may well be a failure of the kernel
ptrace call to retrieve the correct registers from the process.
> 
> > It's conceivable that the frame pointer was corrupted.  But 
> in this case,
> > even the first register dump (at the expected SIGSEGV) 
> shows a similarly bad
> > frame pointer.  I find it hard to believe that the process 
> could have
> > correctly continued even this far if %fp was already 
> corrupted there.
> 
> Or are you really meaning that the register dump is wrong, i.e., that
> gdb somehow dumps the registers wrongly? (Can't it be something else
> yielding wrong values to gdb?)

Gdb somehow gets the values wrong.  That may be a kernel problem.  Or it may
be that gdb uses the wrong method to retrieve them.  (It might need to look
for the register values in the memory stack, and it might look in the wrong
place.)
> 
> > For the optimized code you tried earlier, gdb was looking 
> for some of the
> > values in registers, where it did find something.  But I 
> wouldn't trust that
> > either.  Unfortunately, I think that means we have not much useful
> > information about what's really going on here.
> 
> Sure, agreed. But still, it gctest fails, that can't be caused by gdb,
> right?
There is still an unexplained gctest failure.  The problem is that we have
no reliable data to debug the problem.
> 
> > If you can't get a working gdb, you might try inserting 
> printfs of the
> > values I suggested earlier directly in the code.  It looks like it's
> > crashing very early on, so you might not get that much output.
> 
> I'll see what I can do. Perhaps we could get some help from other
> people having other variants of sparc-linux to test also.
> 
I can't help much since I don't have access to a SPARC Linux system.  I
agree that getting some input from the SPARC Debian developers would be
helpful.

Hans
> 
> > 
> > > -----Original Message-----
> > > From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> > > Sent: Tuesday, February 12, 2002 12:38 PM
> > > To: Boehm, Hans
> > > Cc: 'Christian Jönsson'
> > > Subject: Re: boehm-gc test failure on sparc-linux
> > > 
> > > 
> > > On Tue, Feb 12, 2002 at 12:03:45PM -0800, Boehm, Hans wrote:
> > > > Could you please build with just -g?  -g -O2 generally 
> > > doesn't give you
> > > > reliable debug information.
> > > > 
> > > > I would prefer if you did
> > > > 
> > > > cp Makefile.direct Makefile; make test
> > > 
> > > OK, but I changed this:
> > > 
> > > chj@fw:~/gc6.1alpha3$ diff Makefile Makefile.direct 
> > > 22c22
> > > < CC=gcc-3.0 $(ABI_FLAG)
> > > ---
> > > > CC=cc $(ABI_FLAG)
> > > 33c33
> > > < CFLAGS= -g -I$(srcdir)/include -DATOMIC_UNCOLLECTABLE 
> > > -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT 
> -DALL_INTERIOR_POINTERS
> > > ---
> > > > CFLAGS= -O -I$(srcdir)/include -DATOMIC_UNCOLLECTABLE 
> > > -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT 
> -DALL_INTERIOR_POINTERS
> > > chj@fw:~/gc6.1alpha3$ 
> > > 
> > > attached is the log output of make test and here's the gdb run:
> > > 
> > > Current directory is ~/gc6.1alpha3/
> > > GNU gdb 5.1
> > > Copyright 2001 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public 
> > > License, and you are
> > > welcome to change it and/or distribute copies of it under 
> > > certain conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB.  Type "show 
> > > warranty" for details.
> > > This GDB was configured as "sparc-linux"...
> > > (gdb) r
> > > Starting program: /home/chj/gc6.1alpha3/gctest 
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00019af8 in GC_SysVGetDataStart (max_page_size=Cannot 
> > > access memory at address 0x1000044
> > > ) at os_dep.c:1055
> > > (gdb) c
> > > Continuing.
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x000199f4 in GC_find_limit (p=Cannot access memory at 
> > > address 0x90022144
> > > ) at os_dep.c:641
> > > (gdb) print GC_stackbottom
> > > $1 = 0xf0000000 <Address 0xf0000000 out of bounds>
> > > (gdb) info registers
> > > g0             0x0	0
> > > g1             0x67	103
> > > g2             0x4e	78
> > > g3             0x40614	263700
> > > g4             0x0	0
> > > g5             0x0	0
> > > g6             0x0	0
> > > g7             0x70	112
> > > o0             0x37f00	229120
> > > o1             0x405fc	263676
> > > o2             0x0	0
> > > o3             0x0	0
> > > o4             0xf350c000	-212811776
> > > o5             0xa	10
> > > sp             0xefffe670	-268442000
> > > o7             0x19a00	104960
> > > l0             0x40000858	1073743960
> > > l1             0x1000000	16777216
> > > l2             0x10bfffe6	281018342
> > > l3             0x1000000	16777216
> > > l4             0x7fffffc3	2147483587
> > > l5             0x1000000	16777216
> > > l6             0xd007a048	-804806584
> > > l7             0x80a22000	-2136858624
> > > i0             0x12800008	310378504
> > > i1             0x1000000	16777216
> > > i2             0x11000101	285212929
> > > i3             0x921221fc	-1844305412
> > > i4             0x901221fc	-1877859844
> > > i5             0xd0020000	-805175296
> > > fp             0x90022100	-1878908672
> > > i7             0xd0224000	-803061760
> > > y              0x7000000	117440512
> > > psr            0x40400081	1077936257	icc:-Z--, 
> > > pil:0, s:1, ps:0, et:0, cwp:1
> > > wim            0x0	0
> > > tbr            0x0	0
> > > pc             0x199f4	104948
> > > npc            0x199f8	104952
> > > fpsr           0x821	2081	rd:N, tem:0, ns:0, ver:0, 
> > > ftt:0, qne:0, fcc:>, aexc:1, cexc:1
> > > cpsr           0x0	0
> > > (gdb) c
> > > Continuing.
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x0001cd24 in GC_mark_from (mark_stack_top=Cannot access 
> > > memory at address 0x913a2049
> > > ) at mark.c:654
> > > (gdb) print GC_stackbottom
> > > $2 = 0xf0000000 <Address 0xf0000000 out of bounds>
> > > (gdb) info registers
> > > g0             0x0	0
> > > g1             0xefffe5e8	-268442136
> > > g2             0x10	16
> > > g3             0x10	16
> > > g4             0x1c750	116560
> > > g5             0x6c642d	7103533
> > > g6             0x0	0
> > > g7             0xffff0000	-65536
> > > o0             0xeffff120	-268439264
> > > o1             0xeffff120	-268439264
> > > o2             0xefffef28	-268439768
> > > o3             0x20	32
> > > o4             0x500adfe4	1342889956
> > > o5             0x5d78	23928
> > > sp             0xefffe528	-268442328
> > > o7             0x1d348	119624
> > > l0             0x400009bc	1073744316
> > > l1             0x1000000	16777216
> > > l2             0x10bffd02	281017602
> > > l3             0x1000000	16777216
> > > l4             0xd007bf9c	-804798564
> > > l5             0x40000964	1073744228
> > > l6             0x1000000	16777216
> > > l7             0x10bffcfd	281017597
> > > i0             0x1000000	16777216
> > > i1             0xd007bfa0	-804798560
> > > i2             0xd207bfa4	-771244124
> > > i3             0x90220009	-1876819959
> > > i4             0xd027bfa0	-802701408
> > > i5             0xd007bfa0	-804798560
> > > fp             0x913a2005	-1858461691
> > > i7             0x932a2002	-1825955838
> > > y              0x7000000	117440512
> > > psr            0x40900080	1083179136	icc:N--C, 
> > > pil:0, s:1, ps:0, et:0, cwp:0
> > > wim            0x0	0
> > > tbr            0x0	0
> > > pc             0x1cd24	118052
> > > npc            0x1cd28	118056
> > > fpsr           0x821	2081	rd:N, tem:0, ns:0, ver:0, 
> > > ftt:0, qne:0, fcc:>, aexc:1, cexc:1
> > > cpsr           0x0	0
> > > (gdb) print descr
> > > Cannot access memory at address 0x913a1f89
> > > (gdb) print mark_stack
> > > Cannot access memory at address 0x913a204d
> > > (gdb) c
> > > Continuing.
> > > 
> > > Program terminated with signal SIGSEGV, Segmentation fault.
> > > The program no longer exists.
> > > (gdb) quit
> > > 
> > > Debugger finished
> > > 
> > > 
> > > Is this what you wanted?
> > > 
> > > Anything else?
> > > 
> > > /ChJ
> > > 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]