Georg Baum wrote:
Kornel Benko wrote:
Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum:
From this I suspect that your iconv can't handle latin9. If that is true
the attached patch (which should go in anyway) should help, and you
should also see an error message on the console from iconv_open.
It still crashes.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087032608 (LWP 28978)]
0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
#1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6
#2 0x08524d86 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:56
#3 0x08526d1c in ~pair (this=0xbfffb3e0) at unicode.C:286
#4 0x08525d13 in lyx::ucs4_to_eightbit (ucs4str=0x8ee953c, ls=56,
[EMAIL PROTECTED]) at unicode.C:298
I see now: This is the problem. Inserting the new IconvProcessor into the
map calls the copy constructor -> iconv_close gets called twice for the
same conversion descriptor.
That means that IconvProcessor must not be copied. Abdel, do you have any
idea how to solve that?
Maybe just remove the iconv_close in the destructor? This is not
strictly needed I think and I put that just for clarity.
We could implement our own copy constructor and
assignment operator that opens a new decsripor, but I am not sure I like
that. Basically we should be able to inherit from boost:noncopyable and
never copy an IconvProcessor, but then we can not use a map.
Whatever container we use the destructor will always be called on
insertion, I think...
If the iconv_close is really needed, we need just to do that explicitly
when we need it instead of doing that in the destructor.
Abdel.
