When running xchat-gnome I'm flooded by crash message

Does xchat-gnome crash?

that's due to the absence notifier plugin and the crash notifications come from apport

The real bug is in xprop, of course, but we need to handle this case more gracefully in apport.

IRC discussion for the records:

<seb128> maybe stop creating bugs if the process loop crash
<seb128> the loop is probably easy to determine
<seb128> like >3 crashes in a min
<seb128> creating bugs for that binary I mean
<pitti> sure, I can define an inhibition period, but how long should that be?
<pitti> the problem is right now, as soon as you click on the dialog, the report will be marked as 'read' and overwritten on next crash
<seb128> I would say "if app crashed > 3 times in a min, open a dialog saying crashes from that app are not going to generated from now"
<pitti> I can make it to not be marked as read before you actually OK it (right now that happens)
<seb128> can't you use the log or something to figure how many times it crashed already?
<pitti> seb128: not how many ATM, just the last time
<pitti> seb128: however, I can add a counter to the report
<seb128> and say something like "that app crash in a loop we stop making bugs for it, remove that lock if you want to get crashes again after fixing the issue"
<pitti> ok, so I'll add a counter to the report
<pitti> and if it exceeds 5, I do not create a new one any more
<seb128> pitti: looks good to me
<pitti> I'm only unsure where I offer the user to remove the report (or reset the counter)
<seb128> 5 by some unit of time
<pitti> well, reports are automatically removed after 7 days anyway
<seb128> yeah, but 5 evolution,firefox crashers in a week can happen
<pitti> ok, so maybe 5 on a day?
<pitti> if it crashes more often, most users will be frustrated enough to not file any more bugs :)
<seb128> right
<seb128> 5 a day looks fine to me
<pitti> ok, that should be doable with a counter and the already existing date
<pitti> if the previous report is on the same day, I increment, otherwise I reset it to zero
<pitti> and if it reaches 5, I stop

 apport (0.12) edgy; urgency=low
 .
   * apport-gtk: Make bug report window resizable when the details are
     expanded. Closes: LP#56672
   * apport_utils.py: Add get_recent_crashes() and a test suite check for it.
   * apport: If the same binary produced more than 5 crashes in the last 24
     hours, ignore the crash. This is a hideous and pretty ad-hoc band-aid to
     avoid flooding users with reports for continuously crashing respawning
     processes. Closes: LP#56362
   * apport: Clean up exit codes to only exit with 0 if report was created, and
     with 1 otherwise (to become more compatible to proposed future kernel
     behaviour, where core dumps are only generated on demand).
   * Add run-tests script which calls all available selftests.
   * debian/rules: Run run-tests during build to have the package FTBFS on
     regressions. Add python build dependency for this (it is already there
     implicitly anyway).

So, let's fix xchat-gnome's bug now.

Baptiste i suppose it's a problem in the autoaway plugin. Could you test without this plugin loaded please?

The issue is due to the autoaway plugin. It's not happening at the moment, bug I workaround the "xprop crashing every second" by unloading that plugin when it was happening

It's strange because it's in the xscreensaver backend but i suppose you're using gnome-screensaver. Don't you?

Do you have any error message in the console when the plugin is loaded?

I use gnome-screensaver, nothing on the command line from where I start xchat-gnome

from the crash report log: "Core was generated by `xprop -f _SCREENSAVER_STATUS 32ac -root _SCREENSAVER_STATUS'."

crash from xprop:

"Starting program: /usr/bin/xprop -f _SCREENSAVER_STATUS 32ac _SCREENSAVER_STATUS -root
_SCREENSAVER_STATUS
Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d8e760 in *__GI_raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d8fee3 in *__GI_abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0804ba00 in Get_Window_Property_Data_And_Type (atom=430, length=0xbfa1d760, type=0xbfa1d75c, size=0xbfa1d758)
    at ../xprop.c:1203
#4 0x0804ba98 in Get_Property_Data_And_Type (atom=430, length=0xbfa1d760, type=0xbfa1d75c, size=0xbfa1d758)
    at ../xprop.c:1216
#5 0x0804bb07 in Show_Prop (format=0x0, dformat=0x0, prop=0xbfa1f985 "_SCREENSAVER_STATUS") at ../xprop.c:1235
#6 0x0804be14 in Handle_Prop_Requests (argc=0, argv=0xbfa1da38) at ../xprop.c:1319
#7 0x0804d15a in main (argc=1, argv=0xbfa1da34) at ../xprop.c:17"

looks like a xprop issue then. Does xchat-gnome needs to make that call every second?

I suppose (hope?) there is a better way to do that with gnome-screensaver and some dbus magic.
IMHO we should drop xscreensaver backend and give some love to the plugin to improve that.

I open a upstream bug about the bad backend used bug.
Please let's continue the discussion there to try to fix that problem.
http://bugzilla.gnome.org/show_bug.cgi?id=354306

I fixed the upstream bug about the wrong backend used.
It should use gnome-screensaver instead of X11 now.
Testing welcome.

But there is still the problem in the X11 backend.

Patch applied to the edgy package:

 xchat-gnome (1:0.13-0ubuntu5) edgy; urgency=low
 .
   * debian/patches/97_from_svn_gnome_screensaver_new_method.patch:
     - patch from SVN, makes the gnome-screensaver plugin work with the
       new dbus method used by it

Fixed in 1:0.13-0ubuntu5