I've noticed the following problem using samba/xine-ui: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed. This happens when utf-16 iconv module is loading. The bug is easy to replicate - just try to run xine-ui. # xine This is xine (X11 gui) - a free video player v0.99.4. (c) 2000-2004 The xine Team. xine: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed. Aborted
Send a self-contained test case. Not some reference to a program with dubious quality.
Do you have a usable testcase for this?
(In reply to comment #2) > Do you have a usable testcase for this? No, in all cases i've tested everything is fine. The problem must be elsewhere.
No idea where the bug is, but when i use libiconv xine works. Maybe my glibc libraries are corrupted, but they works for most of programs (except of xine and samba). Also iconv tool converts codepages well. I have no time to debug xine and glibc. I found few persons on google (http://www.google.pl/search?hl=pl&q=+gconv_db.c%3A232%3A&btnG=Szukaj&lr=) who have the same problem, so maybe someone else someday will try to resolve this problem :) The same bug was reported on samba's bugzilla (https://bugzilla.samba.org/show_bug.cgi?id=3084), but is not fixed till now.
Sorry guys, this is only samba issue. Xine samba plugin is linked with libsmbclient. Sorry again.
*** Bug 2597 has been marked as a duplicate of this bug. ***
Ah, I managed to reproduce this with something much simpler than samba :-) : #include <iconv.h> int main() { iconv_t cd0, cd1; cd0 = iconv_open("ISO-8859-7", "UTF-16LE"); cd1 = iconv_open("ISO-8859-7", "UTF-16LE"); iconv_close(cd0); iconv_close(cd1); return 0; } It seems that opening two identical conversion descriptors is what triggers the error. Is there any reason why two identical descriptors should not be allowed ? Therefore I think that this is a glibc bug, after all. Perhaps reopening it is in order ? Regards, Theodoros Kalamatianos
(In reply to comment #7) > Ah, I managed to reproduce this with something much simpler than samba :-) : > > #include <iconv.h> > > int main() { > iconv_t cd0, cd1; > cd0 = iconv_open("ISO-8859-7", "UTF-16LE"); > cd1 = iconv_open("ISO-8859-7", "UTF-16LE"); > iconv_close(cd0); > iconv_close(cd1); > return 0; > } > > It seems that opening two identical conversion descriptors is what triggers the > error. Is there any reason why two identical descriptors should not be allowed ? > > Therefore I think that this is a glibc bug, after all. Perhaps reopening it is > in order ? I confirm that on my system this code reproduces the bug. In my opinion this code should work, so i will reopen this bug. Correct me if i'm wrong :) Regards.
I cannot reproduce any problem. Unless you provide detailed reports based on the *current* sources I'll close the bug again.
Actually, I was too quick. It does fail on one machine. I'll look at it.
This is fixed upstream. It was only an incomplete condition of an assert. The actual code is correct.
Only crashes on startup have been reported, so flagging as security-.