I can't reproduce this bug.

On which server do you try to connect?

I just found out that even when I am not connected it crashes. 

I tried to connect to irc.efnet.net this time. (In reply to comment #1)
> I can't reproduce this bug.
> 
> On which server do you try to connect?
> 

I just tried irc.efnet.net. I actually found out that it even crashes when I am not connected to any server, so the program crashes on the /server command.

I am currently running Ubuntu Dapper Drake with an 2.6.15 (-22-686) kernel. So if it isn't reproducable it might be an Ubuntu problem.

I use Dapper too and can't reproduce this crash.

Have you any server marked as autoconnect?

Could you install this package and paste a trace with debug symbols?
http://www.cerkinfo.be/~kujo/xchat-gnome_0.11-0ubuntu5_i386.deb

I have two servers for autoconnect. 

When I have no servers for autoconnect and I type /server <server> then nothing happens (the program does nothing actually; it does not connect).

Stacktrace with the new package:
Backtrace was generated from '/usr/bin/xchat-gnome'

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1225529664 (LWP 7790)]
0xffffe410 in __kernel_vsyscall ()

+ Trace 68289

This crash seems to occur in the autoaway plugin.
Could you try without this plugin loaded please?

Perfect, it works now. 

I forwarded this bug to the author of the autoaway plugin.

I'll take a look at this in the next couple of days. It looks like there's a race since it crashes doing traversal of a GList. 

Is xchat-gnome multithreaded? Are there any guarantees that plugin methods are always called from the same thread? Can plugin methods be called simultaniously from separate threads?

No, there are no threads.

Created attachment 66256 [details] [review]
Patch that *might* fix the issue

I can't reproduce the error here (ubuntu dapper, using xchat-gnome from trunk), but the only thing I can think of that could be causing this is a null pointer passed to strcmp.

This patch ensures that null won't be passed to it, and also changes the collating function to one that handles UTF-8 encoded strings.

Jaco, could you try this patch and say if it fixs your crash please?

I patched autoaway, but now the program crashes when I type. I have attached the backtrace.

Created attachment 66301 [details]
Backtrace after patch.

Hmm.. Jaco: Could you try running these two commands from the terminal:

xprop -f _SCREENSAVER_STATUS 32ac -root _SCREENSAVER_STATUS

and

xscreensaver-command --time

If I run xprop to get the screensaver status on Ubuntu Dapper, it gets terminated by SIGABRT.. This worked fine on Breezy when I wrote this plug-in. Does anyone with more X11 knowledge have a clue about what could be causing this? 

xprop -f _SCREENSAVER_STATUS 32ac -root _SCREENSAVER_STATUS
_SCREENSAVER_STATUSAborted

xscreensaver-command --time
xscreensaver-command: no screensaver is running on display :0.0


The xscreensaver is not running at my system, instead I should have gnome-screensaver but intrestingly enough it doesnt seem to be running either.

I tried to enable both xscreensaver and gnome-screensaver manually, but no change.

Remarkebly my auto-join server did not respond and when I tried the /server command it worked. But when I closed the program, restarted it and choose a server with the connectbox from the menu it crashed. 

Somehow it seems to be getting more random - the stacktrace is the same (except for the threadnumbers).

I'm starting to get out of ideas here. The xprop that gets signaled on ubuntu is suspicious, but I tried a simple test program containing only the code in get_screensaver_running_xprop (which seems to be the top of the stacktrace before the signal kills xchat-gnome) and it runs fine (no signal to the app).

Jaco: it would be interesting to see what happens if you manage to get gnome-screensaver up and running. the autoaway plugin should default to that if it can get contact with it over dbus. (you *do* have a dbus enabled build of xchat-gnome, right?)

What do you get by running:

dbus-send --session --dest=org.gnome.ScreenSaver --type=method_call --print-reply  --reply-timeout=2000 /org/gnome/ScreenSaver org.gnome.ScreenSaver.getActive

Expected result is something like:
method return sender=:1.3 -> dest=:1.33
 boolean false

Perhaps we should remove support for x11 screensaver since it seems to cause problems? Or at least not call xprop... Guillaume and David, what are your opinions?

Jaco: Could you also try applying the following patch to see if it's really xprop that is crashing xchat-gnome:
Index: xscreensaver.c
===================================================================
--- xscreensaver.c      (revision 10513)
+++ xscreensaver.c      (working copy)
@@ -83,7 +83,7 @@
 gboolean
 get_xss_screensaver_active (void)
 {
-       if (g_find_program_in_path ("xprop"))
+       if (g_find_program_in_path ("xprop") && FALSE)
                return get_screensaver_running_xprop();
        else if (g_find_program_in_path ("xscreensaver-command"))
                return get_screensaver_running_xs_cmd();

Since gnome-screensaver is now an official GNOME module, IMHO we can safely drop x11 screensaver support.

A lot of people are still running xscreensaver.  I'd prefer to keep support there

OK, it looks like after the patch here, it's getting the same crash as #344340
As such, I'm going to apply it and mark this one fixed.