I upgraded glibc to 2.3.1, and have problems with my jabber-server. It crashes with coredump every time somebody tryes to connect to it. It worked well with glibc 2.2. It don't know if it is really because of glibc. But i tryed to compile it with different gcc's, with different pth versions. Does anybody have the same problem? Is it just truble with my system.
Jabber-Server is working here with glibc-2.3.1-r2 without any problem. For pth you should use pth-1.4.0 since 1.4.1 makes trouble with jabber-server.
I also have problems with jabber-server, when people try to register to one of its transport, this one crashes with a segmentation fault. I have glibc 2.3.1-r2, gcc 3.2.2 and pth 1.4.0.
this happans only with aim-transport: # gdb jabberd/jabberd GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-pc-linux-gnu"... (gdb) run -c /var/tmp/portage/jabber-server-1.4.2-r5/work/jabber-1.4.2/icqtrans.xml Starting program: /var/tmp/portage/jabber-server-1.4.2-r5/work/jabber-1.4.2/jabberd/jabberd -c /var/tmp/portage/jabber-server-1.4.2-r5/work/jabber-1.4.2/icqtrans.xml New session for drey@vocord.rt.mipt.ru/Psi Program received signal SIGSEGV, Segmentation fault. 0x4c133da5 in fixup () from /lib/ld-linux.so.2 (gdb) backtrace #0 0x4c133da5 in fixup () from /lib/ld-linux.so.2 #1 0x4c134000 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #2 0x40021718 in aim_newconn (sess=0x8162078, type=7, dest=0x4003f457 "login.oscar.aol.com") at conn.c:646 #3 0x400360bd in at_session_create (ti=0x815f558, aim_data=0x8175510, jp=0x8173c18) at sessions.c:872 #4 0x4002ae06 in at_auth_user (ti=0x815f558, jp=0x8173c18) at jabber_auth.c:48 #5 0x4002ed64 in at_server_pres (ti=0x815f558, jp=0x8173c18) at pres.c:20 #6 0x4002e99f in at_parse_packet (arg=0x8173c08) at parser.c:65 #7 0x08055d9d in mtq_main (arg=0x80bd130) at mtq.c:151 #8 0x4c277cb9 in pth_spawn_trampoline () from /usr/lib/libpth.so.14 #9 0x4c186674 in makecontext () from /lib/libc.so.6 (gdb) It seems something wrong with glibc.
It seems it works well with glibc-2.3.2.
Will depend on >glibc-2.3.2 and close once it is marked stable.
Depending on the progress of glibc, I recommend making a seperate ebuild for the transports and making that dependant on >glibc-2.3.2. The jabber server itself seems to run well enough, but from my own personal testing the majority of these transports will segfault with this version of glibc, and the amount of documentation for this particular bug is rather scarce. (assuming you're a jabber newbie or haven't thought to check the bugtracker) Additionally, the MSN transport has a memory leak that is officially documented on the project's front page. (http://http://msn-transport.jabberstudio.org/) Since the project is not being actively developed further, I highly recommend changing the way the transport is run from /etc/init.d/jabber. Preferably it needs to be scripted in some way that it automaticly dies and respawns at a fixed interval. I've also noticed that the jabberd instances will occasionally leave their .pid file behind even if they're shutdown cleanly. This bug can be reproduced reliably. The user will have to manually remove the .pid files left behind in /var/spool/jabber before the associated jabberd instance can be started again. Lastly, this "bug" is beyond the scope of Gentoo to "fix", but you cannot register with the MSN transport unless a user has validated the e-mail address associated with their account. This may confuse some administrators who have newly created a MSN account solely for the purpose of testing the transport, as the official MSN client will allow you to log on even if you haven't validated your account.
I got a little carried away there. Let me know if I should go ahead and create new bugs for the others I mentioned.
Yes, please do create seperate bugs for the problems not related to glibc... Moving the transports into seperate packages would be a problem, as there is currently no way to have a 'jabber.d' directory merged into the XML configuration file. Also, do you know which specific transports depend on >=glibc-2.3.2? I could make the dependency based on the local use flags (j-nomsn etc).
In summary, I think all of our problems would go away if the new glibc would get listed as stable. jabberd-server is installable as long as glibc !=2.3.1. (it occured to me that the dependency need not be >2.3.1, as it's a bug specific to this version) This would require minimal changing of the package layout. One approach would be, at least tempoarily, have two jabber-server packages; one for a standalone jabber server, and one for the server with transports. The package with the transports included would have the glibc !=2.3.1 dependency. Overall, I feel that this solution would achieve the desired results of allowing users to run a jabber server, and preventing the installation of the transports on glibc 2.3.1 (without requiring an /etc/jabber.d setup). In the end this might be for the best anyway, as it prevents jabber newbies from adding components they might not want to use. Y'know, the same reasoning for why everything installed to /etc/xinetd.d set "disabled = yes" by default. As for which ones segfault, aim-t and yahoo are confirmed for sure. I wasn't properly registering myself on MSN until after I fixed my glibc problem, so I'm unable to say whether or not the problem exists in it as well.
jabber-server-1.4.2-r3 now DEPENDs on !=sys-libs/glibc-2.3.1 if any transports are enabled. Note that bug 26440 prevents emerging of 1.4.2-r3 currently, so I have not tested this, though it should work.
