Re: master with threaded gc

[Mike Gran <spk121@yahoo.com>]

> From: Ludovic Courtès <ludo@gnu.org>
>> Greg Troxel writes:
> 
[...]
> 
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x00007f7ffd6cac90 in strcmp () from /usr/lib/libc.so.12
> > (gdb) bt
> > #0  0x00007f7ffd6cac90 in strcmp () from /usr/lib/libc.so.12
> > #1  0x00007f7ffd65f23e in _citrus_iconv_open () from /usr/lib/libc.so.12
> > #2  0x00007f7ffd64dc6f in iconv_open () from /usr/lib/libc.so.12
> > #3  0x00007f7ffdbd075f in rpl_iconv_open (tocode=0x7f7ffdbd4a2b "UTF-8", 
> fromcode=0x7f7ffdbded05 "ISO-8859-1") at iconv_open.c:111
> > #4  0x00007f7ffdbcf22f in mem_iconveh (src=0x6a3530 " - arguments: ", 
> srclen=14, from_codeset=0x7f7ffdbded05 "ISO-8859-1", to_codeset=0x7f7ffc4290ec 
> "646", 
> 
> Does it help to use GNU libiconv instead of NetBSD’s libc for iconv(3)?
> 
> Does libunistring’s ‘configure’ complain about the lack of libiconv?

FWIW, rpl_iconv_open() is the gnulib wrapper to iconv_open.  It is
supposed to try various alternative names for codesets until it finds
one that works with the underlying system iconv_open.  But the line it 
crashes at (iconv_open.c:111) is just an ordinary call to iconv_open, 
so the strcmp segfault is unexpected.

It could be that the tocode string "UTF-8" is being GC'd before 
it is tested because the port is GC'd, but that seems unlikely.

There is another curious thing, which may be unrelated

>> #6  0x00007f7ffdb80605 in scm_lfwrite_str (str=0x6e4720, port=0x5bcba0) at ports.c:1276
>> #7  0x00007f7ffdb848fc in iprin1 (exp=0xfffffffffffffff8, port=0x5bcba0, pstate=0xdd6770) at print.c:723
>> #8  0x00007f7ffdb84f18 in scm_prin1 (exp=0x6e4720, port=0x5bcba0, writingp=0) at print.c:890

In the above, 'exp' is an SCM string that is being passed down from func to 
func.  It is weird that its address jumps from 0x6e4720 to 
0xfffffffffffffff8 then back to 0x6e4720.  That shouldn't happen.

-Mike