Re: Sylpheed crashing

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

On Tue, 3 Jan 2017 20:32:13 -0500 "Ian D. Leroux"
<idleroux%fastmail.fm@localhost> wrote:
> Interestingly, while the fault is intermittent in general (I sometimes
> go several days between crashes), once execution reaches _fini ()
> from /usr/lib/i18n/libmapper_zone.so.5.0 the stack-trashing and
> subsequent crash happen consistently. To my untrained eye it looks
> like something is going wrong down in libc, which is worrisome.
> Further hints welcome. 
> 
> (gdb) bt
> #0  0x00007ddca8200c80 in _fini () from /usr/lib/i18n/libmapper_zone.so.5.0
> #1  0x00007f7ff7c05df8 in _rtld_unload_object.part.8 () from /usr/libexec/ld.elf_so
> #2  0x00007f7ff7c06319 in dlclose () from /usr/libexec/ld.elf_so
> #3  0x00007ddcacea3fb6 in ?? () from /usr/lib/libc.so.12
> #4  0x00007ddcab200a91 in ?? () from /usr/lib/i18n/libiconv_std.so.5.0
> #5  0x00007ddcab200ae2 in ?? () from /usr/lib/i18n/libiconv_std.so.5.0
> #6  0x00007ddcab200b30 in ?? () from /usr/lib/i18n/libiconv_std.so.5.0
> #7  0x00007ddcace708b0 in ?? () from /usr/lib/libc.so.12
> #8  0x00007ddcace70f80 in _citrus_iconv_close () from /usr/lib/libc.so.12 
> #9  0x00007ddcace5c19f in iconv_close () from /usr/lib/libc.so.12
> #10 0x00007ddcb88222a9 in conv_iconv_strdup(
>     inbuf=0x72544b5a2d10 "xxxxxxxxxxxxxxxxxxx\n",
>     src_code=0x7ddcb591d0f0 "ISO-8859-1",
>     dest_code=0x7ddcb8876bfb "UTF-8", error=0x0) at codeconv.c:1525
> #11 0x00007ddcb8821f37 in conv_convert (conv=0x7ddcb5924280,
>     inbuf=0x72544b5a2d10 "xxxxxxxxxxxxxxxxxxxx\n") at codeconv.c:1380
> #12 0x000000000045c744 in textview_write_line(textview=0x7ddcb8fa08d0,
>     str=0x72544b5a2d10 "xxxxxxxxxxxxxxxxxxxx\n", conv=0x7ddcb5924280) at
>     textview.c:1544

I'm trying to understand the last 10 stack frames that take us from the seemingly sensible (sylpheed closing an iconv_t after having converted some text to utf-8) to the soon-to-be fatal (the call to _fini whose stack later gets trashed). The first three stupid questions that arise are:
- what does the ".part.8" in frame #1 mean? "_rtld_unload_object.part.8" isn't a legal C identifier, so what's it doing as a function name in the backtrace?
- where are the sources for libmapper_zone? There are no source files in src/lib/i18n_module/mapper_zone
- Is there a standard procedure for rebuilding the base system dynamic libraries (like libc and libmapper_zone) with debug symbols?

Also, since this is looking more and more like a base system problem, what's the right list for me to pester?  current@?

Thanks for your patience as I learn the ropes ...

--
IDL