Re: Sylpheed crashing

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Wed, 21 Dec 2016 22:55:24 -0500 "Ian D. Leroux"
<idleroux%fastmail.fm@localhost> wrote:

> On Wed, 21 Dec 2016 21:02:39 +0100 Tobias Nygren <tnn%NetBSD.org@localhost>
> wrote:
> > No issues here. The stack looks trashed though. I'd expect every
> > trace for thread 1 to lead back to g_main_loop_run() from glib2.
> > Note: Sylpheed nowadays uses a separate worker thread for imap i/o
> > so it might be useful to get a backtrace for all running threads.
> 
> gdb reports that the other threads have finished and refuses to switch
> to them or print backtraces for them (while examining the core file).
> There's probably no point fussing about this until I manage to
> reproduce the crash with debug symbols to give us a usable backtrace.
> I'll try to do that as soon as the current pkg_rr run completes.

I've rebuilt sylpheed, gtk and glib with debug symbols, but the
backtrace still looks the same for thread 1:

(gdb) bt
#0  0x000078c2f34c50f3 in ?? ()
#1  0x000078c2f3000675 in ?? () from /usr/lib/i18n/libmapper_zone.so.5.0
#2  0x000078c305477aa0 in ?? ()
#3  0x000078c2f3000c89 in _fini () from /usr/lib/i18n/libmapper_zone.so.5.0
#4  0x0000000000000000 in ?? ()

All other threads are marked as "Terminated". I suppose this isn't too
surprising if the untrashed remnant of the stack corresponds to calls
within base system libraries, which still have no debug symbols. I
haven't rebuilt the base system since long before sylpheed started
crashing, so I don't think the problem is there (unless some change in
sylpheed is exposing a long-hidden bug in base).

I'm wondering how the stack gets trashed. Clearly it's not the
immediate cause of the segfault (since we're still 4 returns away from
the null pointer when the core gets dumped), but it's probably
related. Can the damage have happened before the call into _fini (), or
is it a consequence of bad arguments in one of the four function calls
that we can see? Is there an easy way to figure out what code calls
_fini ()? I tried grepping the sources, but, the string "_fini" shows
up everywhere, often as a substring of names like
"<something>_finished".

--
IDL