Re: boehm-gc test failure on sparc-linux
This thread is also forwarded to the debian sparc list.
The problem is that the boehm garbage collector (gc) test in the
gcc-3.1 test suite fails on (Debian woody) sparc-linux. It might be
binutils problem, it might be a gcc problem (it could perhaps be a
glibc problem) and it coule be a gc problem. Any help is greatly
appreciated.
If you're interested and could assist, please hop in at
http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00194.html
and more info on the gc can be found at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html
and the download is here:
http://ginger.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.1alpha3.tar.gz
Cheers,
/ChJ
On Wed, Feb 13, 2002 at 09:31:25AM -0800, Boehm, Hans wrote:
> > 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
> > > >
> >
Reply to: