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: "Boehm, Hans" <hans_boehm at hp dot com>
- To: 'Christian Jönsson' <c dot christian dot joensson at telia dot com>, "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Feb 2002 09:31:25 -0800
- Subject: 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
> > >
>