This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: boehm-gc test failure on sparc-linux
- From: Christian Jönsson <c dot christian dot joensson at telia dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: 'Christian Jönsson' <c dot christian dot joensson at telia dot com>,gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Feb 2002 07:32:36 +0100
- Subject: Re: boehm-gc test failure on sparc-linux
- References: <40700B4C02ABD5119F000090278766443BEFB5@hplex1.hpl.hp.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?
> 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...)
> 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'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?)
> 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?
> 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.
Cheers,
/ChJ
>
> > -----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
> >