How to Trap a Crashing App ??

GTrax · 08-29-2010, 05:42 AM

Hi LQ Folk

I would like to learn the right way, or some neat technique, to discover why a compiled-from-source application just unaccountably quits. I am looking for approach advice, since it it easy enough to discover that the pre-compiled version from Ubuntu does work just fine.
My motivation is to explore, and maybe try to modify it a little for myself.

At my level of programming expertise, I have often used the "sh configure, make, make install" route; and sometimes made small changes to the code eg. changing a window size and similar. C and C++ tutorials teach the main rules, but I am no expert at classes, structures or obscure expression tricks.

The application is a QT type called "qantenna", used for electromagnetic simulation of antennas. The source I downloaded from SourceForge. Although a KDE application, the repository version seems to run just fine on my Ubuntu 9.10 Karmic (soon to become Lucid), on its Gnome desktop.

The compiled version behavior is that the main window opens and runs OK, with the GUI view operating with fully alterable views. As soon as a valid antenna file is loaded, the whole application instantly quits.

How does one deal with an application that gives no chance to catch it doing things wrong?

repo · 08-29-2010, 05:52 AM

You could start the application from a terminal
For more debugging you can use strace

xeleema · 08-29-2010, 06:00 AM

Greetingz!

Sounds like your application is having a "Segmentation Fault", which means there should be a "core" file somewhere in the directory the application was started in (or perhaps your home directory).
You can attempt to analyze the "core" file (not an area of my expertise, I'm afraid), or you can try to run your application within a debugger (something I've had to restore to from time to time).

The GNU Debugger "gdb" helps out tremendously in this regards. There are several good guides to using this debugger.

Note that you may have to recompile the application in order to use the debugger.

On a side note, I would check the config.log and output during compilation for any grevious errors. There's probably a library problem somewhere...

Elv13 · 08-29-2010, 01:15 PM

The core files are disabled by default in most distribution, you have to turn it on, Google can help on that. About gdb, just open the application in gdb, the write run then, once crashed "backtrace". If you compiled the program with debug support, it will print the reference in the code where the application crashed.

GTrax · 08-29-2010, 06:05 PM

Quote:

Originally Posted by repo

You could start the application from a terminal
For more debugging you can use strace

Thanks much for the suggestion. The output from strace is huge! Unfortunately, it also significantly modifies the displayed behavior.
Even so - I can see where strace can be useful.

GTrax · 08-29-2010, 06:48 PM

Quote:

Originally Posted by xeleema

On a side note, I would check the config.log and output during compilation for any grevious errors. There's probably a library problem somewhere...

Thanks much xeleema
You could be right about the library.
My first try into checking this one out was to simply set it off in a terminal, instead of using a desktop icon launcher. First I cd to the <path>/bin where the executable got made. The result is as follows..

Code:

<path>/bin$ ./qantenna
(QUrl("file:///usr/local/share/doc/qantenna/examples") )  
NEC output parser - The file does not exist (Yes - we know! The app has to make it first!)

ASSERT failure in QList<T>::at: "index out of range", file /usr/include/qt4/QtCore/qlist.h, line 395
Aborted
<path>/bin$

QList<T> turns out to be a Qt Class Reference http://doc.trolltech.com/latest/qlist.html
Er.. this looks kinda advanced! :O

Code:

    // From qlist.h
393 template <typename T>
394 inline const T &QList<T>::at(int i) const
395 { Q_ASSERT_X(i >= 0 && i < p.size(), "QList<T>::at", "index out of range");
396 return reinterpret_cast<Node *>(p.at(i))->t(); }

I guess somewhere in the source code, QList<T> was used, possibly in unwise manner. This does not mean I know what it is, or what to do with it when I find it. This is one of those situations where some major experiences learning GNU Debug and Classes has first to be done. Best way is to get into trying to do it - I think..

xeleema · 08-30-2010, 02:19 PM

Quote:

Originally Posted by GTrax

Er.. this looks kinda advanced! :O

Code:

    // From qlist.h
393 template <typename T>
394 inline const T &QList<T>::at(int i) const
395 { Q_ASSERT_X(i >= 0 && i < p.size(), "QList<T>::at", "index out of range");
396 return reinterpret_cast<Node *>(p.at(i))->t(); }

I'll let you in on a little coding secret; It's (almost) never the line number the program says it is. Usually it's the line right before the line number it reports.

In this case, however, I will definetly have to agree with you; this is quite a bit out of my range (pardon the pun).
I'm half tempted to ask you; Is there a newer version of the source code for what you're compiling out there somewhere?
Perhaps you could recompile and double-check for any errors?

Maybe a kind moderator can move your thread over to Programming?
(I'm not sure if you, as the Original Poster, could move the thread...I've never started a thread here before...)

Good luck!

GTrax · 08-30-2010, 08:01 PM

Quote:

Originally Posted by xeleema

Maybe a kind moderator can move your thread over to Programming?
Good luck!

Thats OK - its in the right place. The software issue is now with the application creator. I can learn programming in another place.

I have managed to find the originator of the code, and he has had this reported before, though not (so far) been able to reproduce it. We now have some help!

It would seem that the way to deal with programs that suddenly crash is to repeatedly crash them while gathering as many clues as possible using strace, and monitoring the tail of dmesg. Compiling it with debugging symbols option, and using breakpoints at the suspect places will eventually reveal it.

Thanks much for your help.

xeleema · 08-31-2010, 05:28 AM

Quote:

Originally Posted by GTrax

...monitoring the tail of dmesg...

Wait, what? Tailing dmesg? I'm curious, how do you do this?
(A quick copy/paste of the command you use would be most helpful)

10110111 · 08-31-2010, 06:40 AM

Quote:

Tailing dmesg? I'm curious, how do you do this?

Code:

dmesg|tail

? Or, maybe even

Code:

watch "dmesg|tail"

?

GTrax · 08-31-2010, 09:00 AM

Quote:

Originally Posted by xeleema

Wait, what? Tailing dmesg? I'm curious, how do you do this?
(A quick copy/paste of the command you use would be most helpful)

I have used it before to monitor the activity of a program, but only as a copied technique. I was able to see the last 10 lines of dmesg continuously updated every second in a terminal, while I was trying to discover what caused a (different) program mal-behavior.

Firstly - see the LINK re: Linux / UNIX tail command or maybe HERE at WIKI
OR .. if you have the "info" utility installed - ~$ info tail

Particularly - note the -f option from..
tail [+ number] [-l] [-b] [-c] [-r] [-f] [-c number | -n number] [file]
It stands for "follow", and will allow the tail command to enter an endless loop updated every second.

You can leave any number of various file tell-tails continuously updating on the desktop, mostly useful ones from /var/log. You can set the number of lines, and the snapshot interval.
It might be something like -

Quote:

~$tail -l 15 -f /var/log/dmesg

The are more clever variants that will only update when there is some new change to show. An example is inotail which is a souped-up version of tail

If you are really a determined log-watch geek, I have also heard of multitail which delivers a many-coloured version that does something like tail, grep, diff, watch all at once.

GTrax · 08-31-2010, 09:07 AM

Quote:

Originally Posted by 10110111

? Or, maybe even

Code:

watch "dmesg|tail"

?

I should not mislead you folks into thinking I am any kind of expert about tail -f, inotail, or multitail. Its easy enough to make the log monitoring work. The real deal is understanding what you read when they deliver, and knowing what to do about it.

~$tail -f /var/log/messages

G

GTrax · 08-31-2010, 06:36 PM

OK friends. This one is now solved!

By using a combination of tail -f on logfiles, and watching processes in Gnome System Monitor, and also getting down & dirty with a dev tool called QDevelop running in debug mode, plus an inspired guess from the program maintainer that crucial dependencies may be missing, did finally cure this one.

I should not have got here at all - given that the needed program and library WAS mentioned in the documentation

Installing pre-compiled from the repository just automatically pulls it all in. Trying to run the application without the other program and its library present is what causes the instant crash.

On the way .. we all get to mess with "top" and "tail" and several other goodies.

G

xeleema · 08-31-2010, 07:19 PM

Quote:

tail -l 15 -f /var/log/dmesg

Ah, I see. Most of my systems do not have a /var/log/dmesg file. I was under the assumption someone was able to get 'dmesg' to run and show a constantly updating screen, possibly by using a for-loop like

user@server# dmesg ; while true
> do
> dmesg | tail -<some wicked cool options here>
> sleep 1
> done

joec@home · 08-31-2010, 10:53 PM

Quote:

Originally Posted by GTrax

Thanks much for the suggestion. The output from strace is huge! Unfortunately, it also significantly modifies the displayed behavior.
Even so - I can see where strace can be useful.

You can run your program in one shell, then with the "ps" command find the PID (Process ID Number). Then in a different screen connect to the PID with strace.

strace -p 12345