GNU bug report logs - #24764
25.1.50; Another crash in automatic gc

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: michael_heerdegen <at> web.de, 24764 <at> debbugs.gnu.org
Subject: bug#24764: 25.1.50; Another crash in automatic gc
Date: Sat, 22 Oct 2016 15:01:25 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  24764 <at> debbugs.gnu.org
> Date: Sat, 22 Oct 2016 13:41:15 +0200
> 
> >> (gdb) bt full
> >> #0  0x000000000058aae0 in unchain_marker (marker=0x88e9968) at marker.c:605
> >>         tail = 0x2020200020202020 <<<<<<<<<<<<<<<<<<<<<<<<
> >>         prev = 0x2020200020202030 <<<<<<<<<<<<<<<<<<<<<<<<
> >
> > Your marker pointers are actually full of blank (and other ASCII)
> > characters.  So some code somewhere either writes past the end of some
> > stack-based array or otherwise overwrites the stack.
> 
> More likely, BUF_MARKERS is already overwritten.

Could be, perhaps because of this:

> Or maybe your system, too, uses ralloc.c, and this is one more
> manifestation of some buffer or string relocated while some code hangs
> to the C pointers of the original contents.

> Finding the place where a member of a struct buffer is overwritten
> can be done with a watchpoint.

Yes.  But IME just a watchpoint with no conditions gets triggered too
frequently to be useful, which is why a more-or-less specific recipe
for reproducing the problem would be beneficial, because then you
could activate the watchpoint only when it matters, or specify a
condition for it to trigger only when that matters.

For starters, I'd try to see whether 'tail' and 'prev' always have
these values when GC crashes.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.