Bug 3655 - smbclient, smbstatus, smbd gconv_db.c:232 bug
Summary: smbclient, smbstatus, smbd gconv_db.c:232 bug
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.21c
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2006-04-04 00:51 UTC by Aleksey Kostyuk
Modified: 2006-04-25 10:48 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aleksey Kostyuk 2006-04-04 00:51:56 UTC
In #3084 was postet about gconv_db.c:232.

My system is x86 Kernel-2.6.16, GLIBC-2.4, GCC-4.0.3

When I running smbstatus or smbclient or smbd -D, I get (for example):
#smbstatus -v
using configfile = /etc/samba3/smb.conf
smbstatus: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed.

This bug appear after compiling new version glibc (glibc-2.4), before was run glibc-2.3.6
Comment 1 Gerald (Jerry) Carter 2006-04-07 16:56:52 UTC
Jeremy, Looks like LOCALE changes on glibc 2.4.  Here's a potion 
of output from an IRC chat.  Just running 'smbclient' with no args

(16:51:51) NyB: Attempting to register new charset ASCII
(16:51:51) NyB: Registered charset ASCII
(16:51:51) NyB: Attempting to register new charset 646
(16:51:51) NyB: Registered charset 646
(16:51:51) NyB: Attempting to register new charset ISO-8859-1
(16:51:51) NyB: Registered charset ISO-8859-1
(16:51:53) NyB: Attempting to register new charset UCS2-HEX
(16:51:55) NyB: Registered charset UCS2-HEX
(16:51:57) NyB: Substituting charset 'ISO-8859-7' for LOCALE
(16:51:59) NyB: Substituting charset 'ISO-8859-7' for LOCALE
(16:52:01) NyB: smbclient: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed.
Comment 2 Gerald (Jerry) Carter 2006-04-07 16:59:43 UTC
Backtrace in gdb (smbclient with debug symbols).

(16:56:33) NyB: Program received signal SIGABRT, Aborted.
(16:56:35) NyB: 0xffffe410 in __kernel_vsyscall ()
(16:56:35) NyB: (gdb) bt
(16:56:35) NyB: #0  0xffffe410 in __kernel_vsyscall ()
(16:56:35) NyB: #1  0xb7b397a1 in ?? ()
(16:56:35) NyB: #2  0xb7c3fff4 in ?? ()
(16:56:35) NyB: #3  0xb7af89b0 in ?? ()
(16:56:37) NyB: #4  0xbf893630 in ?? ()
(16:56:39) NyB: #5  0xb7b3b0e9 in ?? ()
(16:56:41) NyB: #6  0x00000006 in ?? ()
(16:56:43) NyB: #7  0xbf893514 in ?? ()
(16:56:45) NyB: #8  0x00000000 in ?? ()
Comment 3 Gerald (Jerry) Carter 2006-04-07 17:01:59 UTC
Teh IRC logs were from a former Mandrake 10.0 system manually
upgraded to glibc 2.4 (local compile).  Samba, OpenLDAP, krb5 
have all be recompiled.  Don't know if this would just be easier to 
get a gilb 2.4 box ourselves and reproruce the error.
Comment 4 Jeremy Allison 2006-04-07 17:13:19 UTC
Looks like a problem upgrading glibc on this system to me. Not a generic problem in glibc 2.4 as shown by SuSE 10.1.
Comment 5 Gerald (Jerry) Carter 2006-04-08 11:28:48 UTC
looks to be a local problem with the glibc C build.  SuSE 10.1
is runnign on glibc 2.4 and exhibits no problems.
Comment 6 Theodoros V. Kalamatianos 2006-04-23 14:14:47 UTC
(In reply to comment #5)
> looks to be a local problem with the glibc C build.  SuSE 10.1
> is runnign on glibc 2.4 and exhibits no problems.

Ah, setting LC_CTYPE to en_US seems to work around this problem. But since I live in Greece (el_GR), I can't make this a permanent setting. I think, though, that this is a clear indicative that this is a glibc bug. I tried several other LC_CTYPE settings from various languages, with mixed results. I noticed however that the UTF-8 locales do not have this problem, so it would not show up on any distro that uses utf8 by default. I'll be forwarding this to the glibc people...
Comment 7 Theodoros V. Kalamatianos 2006-04-25 02:30:43 UTC
According to http://sourceware.org/bugzilla/show_bug.cgi?id=2569 this is a samba-only problem. All other occurences where related to the program been linked against libsmbclient. 
Comment 8 Jeremy Allison 2006-04-25 02:59:29 UTC
I need a good backtrace from smbclient. I mean a backtrace with real symbols going all the way up to main :-).
Comment 9 Theodoros V. Kalamatianos 2006-04-25 06:57:28 UTC
Ok, maybe it's a glibc thing after all (this whole story reminds me of a tennis match...). The following reproduces the problem:

#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");
    return 0;

much simpler than samba code, eh ?