Bug 64977 - crash - no user input, no new data, full on kst crash
Summary: crash - no user input, no new data, full on kst crash
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-26 10:22 UTC by Matthew Truch
Modified: 2003-10-02 06:37 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Truch 2003-09-26 10:22:41 UTC
Version:           0.93-devel (using KDE KDE 3.1)
Installed from:    Compiled From Sources
OS:          Linux

Backtrace as below.

No user input to kst (it was in another virtual desktop) at the time of the crash.  There was no live data coming into kst, in fact, blastcom may have been restarted when it happened (exact timing unknown).  

There were 3 other kst's running, which did not crash.  

I'm sorry I don't know any more.  

[New Thread 1098147776 (LWP 2840)]
0xffffe002 in ?? ()
#0  0xffffe002 in ?? ()
#1  0x406c957d in KCrash::defaultCrashHandler(int) ()
   from /usr/lib/libkdecore.so.4
#2  <signal handler called>
#3  0x0805d026 in GetNFrames ()
#4  0x080a0b58 in KstFile::dirfileUpdate() ()
#5  0x0809f62d in KstFile::update(int) ()
#6  0x080b5abd in KstDoc::update(bool) ()
#7  0x080bb0d0 in KstApp::slotTimer() ()
#8  0x080bb59e in KstApp::qt_invoke(int, QUObject*) ()
#9  0x40a62e99 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x40a62d3d in QObject::activate_signal(int) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x40d461db in QTimer::timeout() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x40a83e72 in QTimer::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x40a04bd4 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x40a0439b in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x4065d1e9 in KApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libkdecore.so.4
#16 0x409dfa15 in QEventLoop::activateTimers() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#17 0x409bd2f8 in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#18 0x40a18a16 in QEventLoop::enterLoop() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#19 0x40a188b8 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#20 0x40a04e01 in QApplication::exec() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#21 0x080bde76 in main ()
#22 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
Comment 1 George Staikos 2003-09-26 15:32:20 UTC
Subject: Re: [Kst]   New: crash - no user input, no new data, full on kst crash

On Friday 26 September 2003 04:22, Matthew Truch wrote:
> Backtrace as below.
>
> No user input to kst (it was in another virtual desktop) at the time of the
> crash.  There was no live data coming into kst, in fact, blastcom may have
> been restarted when it happened (exact timing unknown).
>
> There were 3 other kst's running, which did not crash.
>
> I'm sorry I don't know any more.
>
> [New Thread 1098147776 (LWP 2840)]
> 0xffffe002 in ?? ()
> #0  0xffffe002 in ?? ()
> #1  0x406c957d in KCrash::defaultCrashHandler(int) ()
>    from /usr/lib/libkdecore.so.4
> #2  <signal handler called>
> #3  0x0805d026 in GetNFrames ()
> #4  0x080a0b58 in KstFile::dirfileUpdate() ()

  Can you recompile with debug?  Run ./configure --enable-debug 
--prefix=/wherever  , make clean, make install.  Then the backtrace will have 
more information.  This could be related to my fix for the disappearing 
KstFiles, but without a line number it's hard to know exactly what went 
wrong.

Comment 2 George Staikos 2003-09-26 15:41:24 UTC
Subject: kdeextragear-2/kst/kst

CVS commit by staikos: 

Ah this could be the reason.  Does this patch help?

CCMAIL: 64977@bugs.kde.org


  M +8 -7      getdata.c   1.10


--- kdeextragear-2/kst/kst/getdata.c  #1.9:1.10
@@ -268,5 +268,5 @@ struct FormatType *GetFormat(const char 
   sprintf(format_file,"%s/format", filedir);
   fp = fopen(format_file, "r");
-  if (fp ==NULL) {
+  if (fp == NULL) {
     *error_code = GD_E_OPEN_FORMAT;
     Formats.n--; /* no need to free.  The next realloc will just do nothing */
@@ -1327,5 +1327,5 @@ int GetData(char *filename_in, char *fie
   if (filename[strlen(filename)-1]=='/') filename[strlen(filename)-1]='\0';
   F = GetFormat(filename, error_code);
-  if (*error_code!=GD_E_OK) {
+  if (!F || *error_code != GD_E_OK) {
     return(0);
   }
@@ -1364,9 +1364,9 @@ int GetNFrames(char *filename_in, int *e
   if (filename[strlen(filename)-1]=='/') filename[strlen(filename)-1]='\0';
   F = GetFormat(filename, error_code);
-  if (*error_code!=GD_E_OK) {
+  if (*error_code != GD_E_OK) {
     return(0);
   }
 
-  if (F->n_raw==0) {
+  if (!F || F->n_raw==0) {
     *error_code = GD_E_FORMAT;
     return(0);
@@ -1382,6 +1382,7 @@ int GetNFrames(char *filename_in, int *e
          (F->rawEntries[0].size*F->rawEntries[0].samples_per_frame);
 
-  nf-=2;
-  if (nf<0) nf = 0;
+  nf -= 2;
+  if (nf < 0)
+    nf = 0;
   return(nf);
 }
@@ -1411,5 +1412,5 @@ int GetSamplesPerFrame(char *filename_in
   }
 
-  if (F->n_raw==0) {
+  if (!F || F->n_raw==0) {
     *error_code = GD_E_FORMAT;
     return(0);


Comment 3 George Staikos 2003-10-02 06:37:56 UTC
Please reopen if you consider to experience crashes with the patch applied. Be sure 
to include a backtrace with --enable-debug.  Thank you.