Quote:
Originally Posted by Farsight
I've managed to also look in to using strace to generate a text file. There are a huge number of lines in this file - are there any particular ones that I should be looking for that would be useful to you in helping me diagnose issues?
|
Look for lines involving "open(...) = -1" and "read(...) = -1 The -1 indicates a failure . (An "=0" indicates success.) Don't get too excited when you find them because it is normal for applications to look in various places for certain files, fail, and proceed until they find the right place. However, if the file name suggests that it might be some data that mmass needs then it would worth investigating whether that file is missing, corrupt, or in a directory the program isn't searching.
You may see where the shared object file(s) is opened or loaded with the "ld..." command. The only shared object file that I noticed in the source code was called calculation.so (or it might have been plural, calculations.so). If the lines after that indicate a crash (for example, if you see a "core dump" file being opened and written) then this would be a good hint that the problem is in the shared object.
I'll have to do some research before I offer any analysis of your /var/log/messages.
-----
Update:
Code:
May 19 21:58:00 localhost goa[1641]: goa-daemon version 3.2.1 starting [main.c:112, main()]
The goa-daemon is apparently a process associated with gnome, so that looks normal.
Code:
May 19 21:58:02 localhost kernel: [ 54.804670] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
May 19 21:58:02 localhost kernel: [ 54.806797] sd 6:0:0:0: [sdb] Asking for cache data failed
May 19 21:58:02 localhost kernel: [ 54.806802] sd 6:0:0:0: [sdb] Assuming drive cache: write through
There are posts on the web that say that the above messages is associated with a module that is trying to use a USB device like a card reader.
This could be a bug in the module. I think it's unrelated to the problem with mmass.
Code:
May 19 21:58:08 localhost dbus-daemon[933]: ** Message: No devices in use, exit
There are always messages from dbus-daemon in the logs. I've yet to figure out what they mean.
Code:
May 19 21:58:14 localhost abrtd: Directory 'ccpp-2012-05-19-21:58:12-1740' creation detected
May 19 21:58:14 localhost abrt[1743]: Saved core dump of pid 1740 (/usr/bin/python2.7) to /var/spool/abrt/ccpp-2012-05-19-21:58:12-1740 (54775808 by$
May 19 21:58:19 localhost abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-05-17-19:24:38-6933
This shows the termination of the attempt to run mmass and gives the name of the core dump file used to record it. You should be able to find the file. The debugger gdb can read core dump files. However I find what it reports to be cryptic - much less informative that the type of output you get when you use gdb with the "run..." command.
(By the way, you could try using gdb and then run.... without doing any special preparations on python and just see what the "bt" commands says.)
If we use gdb on the core dump, perhaps some forum member has eyes that are educated enough to interpret output. Directions on the web say the command has the form
Code:
gdb /path/to/application /path/to/corefile
I think those directions are imprecise because what worked for me is to put the path to the application, not including the name of the application file and put the path to the core file and include the name of the corefile, which was "coredump" on my machine.
So my guess for what to do in your case is:
Code:
gdb /usr/bin /var/spool/abrt/ccpp-2012-05-19-21:58:12-1740/coredump
(If that doesn't work, try using /usr/bin/python2.7)
In the web example I looked at the output of gdb conveniently gave the line in the program that caused the crash. I expect the command
will output something, but it may be hard to interpret.
Code:
May 19 21:58:19 localhost dbus[933]: [system] Failed to activate service 'org.freedesktop.colord-sane': timed out
May 19 21:58:19 localhost dbus-daemon[933]: dbus[933]: [system] Failed to activate service 'org.freedesktop.colord-sane': timed out
May 19 21:58:19 localhost colord[1534]: (colord:1534): Cd-WARNING **: failed to contact colord-sane: GDBus.Error:org.freedesktop.DBus.Error.TimedOut$
May 19 21:58:19 localhost dbus-daemon[933]: dbus[933]: [system] Failed to activate service 'org.freedesktop.colord-sane': timed out
May 19 21:58:19 localhost colord[1534]: (colord:1534): Cd-WARNING **: failed to contact colord-sane: GDBus.Error:org.freedesktop.DBus.Error.TimedOut$
I think the above messages have to do wih a process that configures the SANE program for scanners. The author of sane-colord explains it here:
http://blogs.gnome.org/hughsie/
Code:
May 19 21:58:19 localhost abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-05-17-19:24:38-6933
May 19 21:58:19 localhost abrtd: Deleting problem directory ccpp-2012-05-19-21:58:12-1740 (dup of ccpp-2012-05-17-19:24:38-6933)
I don't understand why there would be duplicate of a core dump directory.
I just started using nano myself. The "less " command is somewhat safer to use since it won't let you write into the file accidentally. Typing "/" puts you in a search mode. You can enter as string and use "n" to search for the next instance of the string.
Thank you both for your suggestions so far.
Linear Mode
