Adding jabber account without server results in 'Glib-Critical' warnings

[Bas Verhoeven <bitlbee@…>]

Adding a jabber account without specifying a server name (e.g. 'account add jabber test' instead of 'account add jabber test@…') results in two GLib warnings:

Send    PRIVMSG &bitlbee :account add jabber test bla
Recv    :root!root@athena PRIVMSG &bitlbee :Account successfully added
Send    PRIVMSG &bitlbee :account 0 on
Recv    (process:31074): GLib-CRITICAL **: g_hash_table_foreach_remove: assertion `hash_table != NULL' failed
Recv    (process:31074): GLib-CRITICAL **: g_hash_table_destroy: assertion `hash_table != NULL' failed
Recv    :root!root@athena PRIVMSG &bitlbee :jabber - Login error: Incomplete account name (format it like <username@jabberserver.name>)
Recv    :root!root@athena PRIVMSG &bitlbee :jabber - Logging in: Signing off..

I can reproduce this on both 3.0.1 and devel (bzr 753). Backtrace:

#0  0xb77767f2 in ?? () from /lib/ld-linux.so.2
#1  0xb73e4640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb73e6018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb76f0084 in g_logv () from /usr/lib/libglib-2.0.so.0
#4  0xb76f00b6 in g_log () from /usr/lib/libglib-2.0.so.0
#5  0xb76f02eb in g_return_if_fail_warning () from /usr/lib/libglib-2.0.so.0
#6  0xb76d8d1a in g_hash_table_foreach_remove () from /usr/lib/libglib-2.0.so.0
#7  0x0808ae2e in jabber_buddy_remove_all (ic=0x997ab78) at jabber_util.c:695
#8  0x08089215 in jabber_logout (ic=0x997ab78) at jabber.c:314
#9  0x0807b648 in imc_logout (ic=0x997ab78, allow_reconnect=0) at nogaim.c:342
#10 0x08088a9f in jabber_login (acc=0x9969310) at jabber.c:118
#11 0x08079518 in account_on (bee=0x99693b0, a=0x9969310) at account.c:354
#12 0x08068e23 in cmd_account (irc=0x9969198, cmd=0x80e2700) at root_commands.c:542
#13 0x08067b60 in root_command (irc=0x9969198, cmd=0x80e2700) at root_commands.c:67
#14 0x08067a54 in root_command_string (irc=0x9969198, command=0xbfa8ad60 "account") at root_commands.c:34
#15 0x080662f9 in root_privmsg (iu=0x9969dd0, msg=0x997ab22 "account 0 on") at irc_user.c:225
#16 0x08061ef3 in control_channel_privmsg (ic=0x997a218, msg=0x997ab22 "account 0 on") at irc_channel.c:595
#17 0x08063267 in irc_cmd_privmsg (irc=0x9969198, cmd=0x997a128) at irc_commands.c:350
#18 0x08064238 in irc_exec (irc=0x9969198, cmd=0x997a128) at irc_commands.c:752
#19 0x0805d2e7 in irc_process (irc=0x9969198) at irc.c:393
#20 0x0805873a in bitlbee_io_current_client_read (data=0x9969198, fd=0, cond=B_EV_IO_READ) at bitlbee.c:222
#21 0x0806fb0c in gaim_io_invoke (source=0x9969208, condition=G_IO_IN, data=0x99672d0) at events_glib.c:85

Attached is the full stacktrace for bzr 753.

[Bas Verhoeven <bitlbee@…>]

Full backtrace (devel/bzr)

[dx]

Tempted to close this one since it's not a real issue (glib says any assertion failure is 'critical', but these are harmless), but whatever, lowering it to minor.

Can reproduce it in 3.2.2, FWIW.

Also sorry for the delay handling tickets.

[dx]

Can reproduce it in 3.2.2, FWIW.

Well, that's weird. Just looked at the code and apparently a few months ago I made ​this commit that looks a lot like reproducing this issue and fixing it. Probably with a different test case, who knows. Either way, it's fixed.