From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.4) Gecko/20030630 Description of problem: I've downloaded the sources, compiled and run the jabberd-2.0b2 Jabber server. All works well, with one exception: the c2s process (client to server connections handler) hangs when the jabberd 2 server shuts down. Process doesn't react to the TERM signal and can only be killed with the KILL signal. It's 100% reproducible. Debugging info I've collected: 1) When I attach to the running c2s process with strace, I can see that it doesn't do any syscalls - it does nothing. 2) When I attach to the running c2s process with gdb and run backtrace, I can see it has hung in the malloc_consolidate() function from glibc: <snip> Reading symbols from /usr/lib/sasl/libplain.so...done. Loaded symbols for /usr/lib/sasl/libplain.so 0x42074bf4 in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x42074bf4 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x42074249 in _int_malloc () from /lib/tls/libc.so.6 #2 0x4207360b in malloc () from /lib/tls/libc.so.6 #3 0x4017632f in ber_memalloc () from /usr/lib/liblber.so.2 #4 0x40176467 in ber_memrealloc () from /usr/lib/liblber.so.2 #5 0x40174e3c in ber_realloc () from /usr/lib/liblber.so.2 #6 0x40174d3b in ber_write () from /usr/lib/liblber.so.2 #7 0x40173431 in ber_scanf () from /usr/lib/liblber.so.2 #8 0x401736fe in ber_scanf () from /usr/lib/liblber.so.2 #9 0x40174908 in ber_printf () from /usr/lib/liblber.so.2 #10 0x40155faa in ldap_send_unbind () from /usr/lib/libldap.so.2 #11 0x4015c973 in ldap_free_connection () from /usr/lib/libldap.so.2 #12 0x40155eaa in ldap_ld_free () from /usr/lib/libldap.so.2 #13 0x40155c2b in ldap_unbind_ext () from /usr/lib/libldap.so.2 #14 0x40155f0f in ldap_unbind_s () from /usr/lib/libldap.so.2 #15 0x0804d047 in _ldap_free (ar=0x80b5718) at authreg_ldap.c:178 #16 0x0804a88a in authreg_free (ar=0x80b5718) at authreg.c:192 #17 0x08053f43 in main (argc=4, argv=0xbfffe664) at main.c:576 #18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 </snip> 3) When I issue the "next" command, I can see that c2s cannot execute any further - completely nothing happens as if the process was waiting for a function to complete: <snip> (gdb) next Single stepping until exit from function malloc_consolidate, which has no line number information. </snip> ... here it hangs. Version-Release number of selected component (if applicable): glibc-2.3.2-27.9 How reproducible: Always Steps to Reproduce: 1. Create an account "jabber" and perform all the following steps using that account 2. Download jabberd2, apply the patch given in the bug description (additional include path) 3. compile jabberd2 (./configure --prefix=/home/jabber --enable-authreg="anon pipe mysql ldap" --enable-debug --enable-developer && make && make check && make install && echo OK) 4. configure jabberd2 to authenticate in LDAP 5. run it on a terminal with debug on 6. connect as a Jabber user 7. press CTRL-C on the server's terminal to shut it down Actual Results: A c2s process (jabberd's child) stays running, hangs in malloc_consolidate() and doesn't react to TERM signal. Expected Results: All jabberd processes terminate cleanly. Additional info: a) This might be related: to successfully compile jabberd2, I had to add /usr/kerberos/include path to GCC's include paths because it is in a non-standard location: diff -urN jabberd-2.0b2/configure.in jabberd-2.0b2.rh9/configure.in --- jabberd-2.0b2/configure.in 2003-10-08 00:45:26.000000000 +0200 +++ jabberd-2.0b2.rh9/configure.in 2003-10-20 14:04:49.000000000 +0200 @@ -258,6 +258,7 @@ J2_LIB_OPENSSL(0, 9, 6, 2) CFLAGS="$CFLAGS $J2_SSL_INCLUDES" +CFLAGS="$CFLAGS -I/usr/kerberos/include" LDFLAGS="$LDFLAGS $J2_SSL_LIBS" b) the Jabberd 2 server is configured to use LDAP authentication.
Hangs in malloc_consolidate etc. are in 99.9% of cases bugs in memory handling of the application (or its shared libraries). So I'd suggest you to use some memory allocation debugger (ElectricFence, MALLOC_CHECK_=3 or valgrind).
Ping. It's almost a month. If we don't get a reply we must assume this is no real problem.
Sorry, I cannot test it - that system is no more, plus I'm too busy right now... Agree to close this bug.
Cannot reproduce it.