Corewatcher

[Gabriel M. Beddingfield]

I've heard (and had) several complaints with people's hard-
drives filling up because of corewatcher. I had an
enlightening chat with Auke about it, and figured I would
share it... so I extended this wiki page:

http://wiki.meego.com/Quality/bkm/corewatcher

Why is it filling up your hard drive? Because it's config'd
by default to "ask" before submitting data to
http://crashdb.meego.com/ . I'm not sure how well the 'ask'
system works... but if it's Xorg or mcompositor or meego-ux-
daemon crashing on you, it doesn't much matter, eh? There's
no way to ask you. So it does the safe thing, and saves the
info (in case you want to analyze it yourself).

How do I fix it? The easiest way is to edit
/etc/corewatcher.conf and set 'allow-submit' to 'yes'. This
will automatically submit your crashes to crashdb.meego.com.

Hope this helps,
Gabriel

[Niels Mayer]

Something better needs to be setup before I set /etc/corewatcher.conf
'allow-submit' to 'yes' .... something like KDE's Dr. Konqi which
steps you through loading the needed debug packages, and lets you look
over your crashdump before submitting as bug report to bugzilla. (
http://manpages.ubuntu.com/manpages/hardy/man1/drkonqi.1.html )

Until then, this is something I did as soon as I saw corewatcher and
gcc spinning endlessly on all the coredumps in /tmp/ . This behavior,
or corewatcher itself, seems to have been introduced in a recent
update.

$ chkconfig --levels 0123456 corewatcher off
$ chkconfig --list
corewatcher 0:off 1:off 2:off 3:off 4:off 5:off 6:off
$ /etc/init.d/corewatcher stop
$ rm -f /tmp/core.[0-9]* /tmp/corewatcher/*

Niels
http://nielsmayer.com

[Auke Kok]

Post by Niels Mayer
Something better needs to be setup before I set /etc/corewatcher.conf
'allow-submit' to 'yes' .... something like KDE's Dr. Konqi which
steps you through loading the needed debug packages, and lets you look
over your crashdump before submitting as bug report to bugzilla. (
http://manpages.ubuntu.com/manpages/hardy/man1/drkonqi.1.html )
Until then, this is something I did as soon as I saw corewatcher and
gcc spinning endlessly on all the coredumps in /tmp/ . This behavior,
or corewatcher itself, seems to have been introduced in a recent
update.

please don't send workarounds to entirely disable corewatcher, but go
and file a bug first?

The last thing we want is people massively disabling the ONLY debugging
tool we have to put on developers' desks to make them fix crashes.

We have too many people fixing corewatcher up right now, and fixes are
getting in almost daily. keeping it running is vital - we need the crash
data.

Auke

[Niels Mayer]

please don't send workarounds to entirely disable corewatcher, but go and
file a bug first?
The last thing we want is people massively disabling the ONLY debugging tool
we have to put on developers' desks to make them fix crashes.
We have too many people fixing corewatcher up right now, and fixes are
getting in almost daily. keeping it running is vital - we need the crash
data.

I'm hoping the only data being sent the /tmp/corewatcher/*.txt
information from the processed core? Otherwise, how can the user
sanitize what can be a potentially significant privacy violation. In
fact, I can't think of a better way to capture all manner of private
data (stored configurations, private URLs, keys, certificates,
passwords, logins) and get that program to core and then send the core
offsite. But of course, if it's just the contents of the text file (as
below) then I'll go ahead....

The reason why I disabled corewatcher is because I wanted to figure
out what is causing regular core dumps (every few minutes) out of
/usr/libexec/meego-panel-status

Since I'm now running corewatcher "manually" i've changed the prefs:
.............................
*** /etc/corewatcher.conf.~1~ 2011-04-29 03:49:15.000000000 -0700
--- /etc/corewatcher.conf 2011-05-02 12:37:47.832619116 -0700
***************
*** 21,27 ****
#
# Default is "ask" which uses a UI application t ask the user for permission
#
! allow-submit=ask

#
# Set the following variable to "yes" if you want to allow your
--- 21,27 ----
#
# Default is "ask" which uses a UI application t ask the user for permission
#
! allow-submit=yes

#
# Set the following variable to "yes" if you want to allow your
***************
*** 33,39 ****
#
# Delete the coredumps after processing
#
! unlink=no

#
# URL for submitting the backtraces
--- 33,39 ----
#
# Delete the coredumps after processing
#
! unlink=yes

#
# URL for submitting the backtraces

.............................

So now when I want to deal with the cores, I do "sudo
/etc/init.d/corewatcher start" and if I don't
"sudo /etc/init.d/corewatcher stop" ...

Does anybody know how to solve this one -- something I forgot to
install/configure, or a bug. Pretty much anytime I have a terminal up,
I see the following:

meegolem klogd: [ 4169.938463] Process meego-panel-sta (pid: 2216,
ti=c63c8000 task=c6384e60 task.ti=c63c8000)

and an associated dump in /tmp/corewatcher/*.txt:
.........................
analyzer: corewatcher-gdb
architecture: i586
component: meego-panel-status
coredump: /tmp/core.1800
executable: /usr/libexec/meego-panel-status
kernel: 2.6.38.2-8.6-adaptation-pinetrail
package: meego-panel-status-0.3.4-1.2-i586
reason: Process /usr/libexec/meego-panel-status was killed by signal
11 (SIGSEGV)
release: MeeGo release 1.1.99 (MeeGo)
build: Unknown
time: 1304364742
uid: 500

backtrace
-----
[New Thread 1800]
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/lib/libgobject-2.0.so.0.2800.6-gdb.py",
line 9, in <module>
from gobject import register
File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
import gdb.backtrace
ImportError: No module named backtrace
Core was generated by `/usr/libexec/meego-panel-status'.
Program terminated with signal 11, Segmentation fault.
#0 0xb6fe176b in ?? () from /usr/lib/libmeego-panel-status.so.0
#0 0xb6fe176b in ?? () from /usr/lib/libmeego-panel-status.so.0
No symbol table info available.
#1 0xb6fe317c in _view_refresh_items_cb () from
/usr/lib/libmeego-panel-status.so.0
No symbol table info available.
#2 0xb7024e19 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#3 0xb7023afb in g_main_context_dispatch () from /lib/libglib-2.0.so.0
No symbol table info available.
#4 0xb702411f in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#5 0xb70246bd in g_main_loop_run () from /lib/libglib-2.0.so.0
No symbol table info available.
#6 0xb717ea7d in clutter_main () from /usr/lib/libclutter-glx-1.0.so.0
No symbol table info available.
#7 0x08049639 in ?? ()
No symbol table info available.
#8 0xb6e3abb7 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#9 0x08049161 in ?? ()
No symbol table info available.
..........................

-- Niels
http://nielsmayer.com

[Auke Kok]

I'm hoping the only data being sent the/tmp/corewatcher/*.txt
information from the processed core?

obviously, that's the only thing that is sent (plus some basic bits like
package version).

in fact, you can see the entire submitted report verbatim on the crashdb
website. if there's an issue with any of that information, please let us
know.

Otherwise, how can the user
sanitize what can be a potentially significant privacy violation. In
fact, I can't think of a better way to capture all manner of private
data (stored configurations, private URLs, keys, certificates,
passwords, logins) and get that program to core and then send the core
offsite. But of course, if it's just the contents of the text file (as
below) then I'll go ahead....

which is why we're not sending entire core dumps. We think about that
kind of stuff...

Auke