[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24764: 25.1.50; Another crash in automatic gc

From: Eli Zaretskii
Subject: bug#24764: 25.1.50; Another crash in automatic gc
Date: Sat, 22 Oct 2016 15:01:25 +0300

> From: Andreas Schwab <address@hidden>
> Cc: Michael Heerdegen <address@hidden>,  address@hidden
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]