Signal 11 (SIGSEGV) Crash
 

After mostly 1 minute Qtella crashes with this failure. Anyone knows what this means?

I've got Mandrake 9.1

And it's a selfcompiled Qtella 0.6.1

i also get these errors on mandrake 9.1

Almost all signal 11 crashes (segment faults) are caused by a reference to the object of a null pointer, which is address 0x0000.

In almost every OS, and in every UNIX I have ever used, it is illegal for a program to read from or write to address Zero.

The idea behind this is that no program can ever have address zero as part of it's data, so that reading or writing to that address is indicating a bug. The OS traps this, and tells you that you have accessed a memory segment that doesn't belong to you, or in other words a segment fault.

All UNIX systems (i think) use signal 11 for this, although it could use a different signal, and still map it to the segfault error if needed.

Anyway, if that's happening to you, it most likely because a variable is being used without being initialized to point to valid memory. An uninitialized variable usually is forced to contain a zero, just for that reason. When they are initialized, they are set to some valid address, which then allows the use of the variable normally.

There could be other reasons for this to happen, but the reason above is almost always the cause. An incorrectly formed query, with data missing, and not caught before being processed, could also cause a problem like this. But most programs are very careful with incomming data, and verify that they are valid and complete before trying to process then. But that is a possible second cause for a segfault, and again it indicates a bug (or poor programming).

Regards,
--R

Crash fixes
 

I have developed a number of crash fixes, that haven't been merged into qtella yet.

This applies to the current sourceforge anoncvs, but it should also apply to the last release.

David.

Same crash, different system and circumstances
 

Hi,

Just to report that I am experiencing a Signal 11 crash 10-15secs after clicking connect (If I don't the app seems stable but obviously is useless!).

I have a self compiled Qtella-0.6.4 running on Redhat 9.0 (with Kde). Qtella remains in the process list after the crash and dies with a backtrace as follows:

[New Thread 1092418880 (LWP 6942)]
[New Thread 1100811456 (LWP 6943)]
0xffffe002 in ?? ()
#0 0xffffe002 in ?? ()
#1 0x4076e5bd in KCrash::defaultCrashHandler(int) ()
from /usr/lib/libkdecore.so.4
#2 <signal handler called>
#3 0x40224f21 in QApplication::internalNotify(QObject*, QEvent*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#4 0x40224b19 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#5 0x407021e9 in KApplication::notify(QObject*, QEvent*) ()
from /usr/lib/libkdecore.so.4
#6 0x401ffd95 in QEventLoop::activateTimers() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7 0x401dd8e8 in QEventLoop::processEvents(unsigned) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8 0x40238cf6 in QEventLoop::enterLoop() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#9 0x40238b98 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x40225151 in QApplication::exec() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x0809e84b in main (argc=1, argv=0x4068427c) at main.cpp:79
#12 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

Any assistance greatly appreciated.

Ed.

P.s. David: can't work out what to do with your fixes (or if they apply) - sorry am kinda a Linux Newbie (former M$ heavyweight though, and learning fast!).

Re: Same crash, different system and circumstances
 

The only way to understand such crashes is to run "valgrind qtella" (after installing valgrind).
The gdb backtrace is unfortunately not useful.

To apply the fix: you need to be able to compile qtella from sources.
Save fulldif.txt into the qtella sources, launch konsole, go to the qtella sources, then type
patch -p0 < fulldif.txt
It should show a list of files successfully modified. Then recompile as usual.

Production Server problem
 

Hi Guys,

I support an application that is deployed on an AIX(Unix) production server. Every saturday midnight, for some reason, the WebSphere process of the application goes down. When I analyzed the java core dump(the memory image of the WebSphere process at the state of going down) I found that the process had recieved a "signal 11" before going down.

To my dismay, this scenario happens only on saturday nights. All the rest of the days, it runs perfectly alright. Can someone think of a reason for this? Or may you guys be able to direct me to some other useful forum?

Thanks,
Thejasvi V