Bug 118696 - "Change data sample ranges" dialog freezes kst with some datasources
Summary: "Change data sample ranges" dialog freezes kst with some datasources
Status: RESOLVED WORKSFORME
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: unspecified Solaris
: NOR normal
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-20 10:18 UTC by Nicolas Brisset
Modified: 2006-01-26 14:01 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 Nicolas Brisset 2005-12-20 10:18:26 UTC
Version:           1.2.0_devel (using KDE 3.4.0, compiled sources)
Compiler:          gcc version 3.4.3
OS:                SunOS (sun4u) release 5.8

[This is quite bad as your kst session needs to be killed !!!]

The "Change data sample ranges" wizard freezes kst with some datasources, like CDF and netCDF. 

To reproduce (you need to have the netCDF datasource working):
- download an example netCDF file with 1D variables, e.g. http://www.unidata.ucar.edu/software/netcdf/examples/GOTEX.C130_N130AR.LRT.RF06.PNI.nc
- load some variables (e.g. "kst -x time_offset -y ADIFR")
- go to Tools->Change data sample ranges
- check "Count from end"
- type "200" in the "limit" field (or whatever it's called in English :-))
- hit "Apply": kst is FROZEN and can only be KILLED :-( !

This used to work, and still works with ASCII. I suppose there has been a minor change somewhere in kst that has not been propagated to all datasources, as CDF also exhibits the same problem. Hopefully this can be fixed easily...
Comment 1 George Staikos 2005-12-20 15:51:09 UTC
Can't reproduce this.  You'll need to send a backtrace with GDB.  You can break into it when it freezes and get a multi-thread backtrace with "thread apply all where"
Comment 2 Nicolas Brisset 2005-12-20 16:01:20 UTC
As I said, it only happens with some datasources. ASCII does not have the problem, I advise you try it with netCDF, where it (almost !) always freezes !

Program received signal SIGINT, Interrupt.
[Switching to LWP 3]
0xfced92f0 in __sigprocmask () from /usr/lib/libthread.so.1
(gdb) thread apply all where

Thread 12 (Thread 5 (LWP 5)):
#0  0xfced92fc in private___lwp_cond_wait () from /usr/lib/libthread.so.1
#1  0xfcec89b8 in _co_timerset () from /usr/lib/libthread.so.1
#2  0xfcedb124 in _thread_start () from /usr/lib/libthread.so.1
#3  0xfcedb124 in _thread_start () from /usr/lib/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
#0  0xfced92f0 in __sigprocmask () from /usr/lib/libthread.so.1
(gdb) where
#0  0xfced92f0 in __sigprocmask () from /usr/lib/libthread.so.1
#1  0xfcece254 in __bounceself () from /usr/lib/libthread.so.1
#2  0xfcec8204 in cond_wait () from /usr/lib/libthread.so.1
#3  0xfcec8090 in pthread_cond_wait () from /usr/lib/libthread.so.1
#4  0xfd90aa7c in QWaitCondition::wait () from /usr/local/kde/lib/libqt-mt.so.3
#5  0xfd948de0 in QSemaphore::operator++ () from /usr/local/kde/lib/libqt-mt.so.3
#6  0xff210e64 in KstChangeNptsDialogI::updateTimeCombo () from /S/KDE/Vdev/lib/libkstapp.so.1
#7  0xff2a0918 in KstChangeNptsDialog::qt_invoke () from /S/KDE/Vdev/lib/libkstapp.so.1
#8  0xff212210 in KstChangeNptsDialogI::qt_invoke () from /S/KDE/Vdev/lib/libkstapp.so.1
#9  0xfd69c5c4 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#10 0xfd69ced8 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#11 0xfd765c6c in QListBox::setSelected () from /usr/local/kde/lib/libqt-mt.so.3
#12 0xfd76158c in QListBox::setSelected () from /usr/local/kde/lib/libqt-mt.so.3
#13 0xff2120d0 in KstChangeNptsDialogI::updateChangeNptsDialog () from /S/KDE/Vdev/lib/libkstapp.so.1
#14 0xff246188 in KstApp::updateDialogs () from /S/KDE/Vdev/lib/libkstapp.so.1
#15 0xff246958 in KstApp::registerDocChange () from /S/KDE/Vdev/lib/libkstapp.so.1
#16 0xff255b54 in KstApp::qt_invoke () from /S/KDE/Vdev/lib/libkstapp.so.1
#17 0xfd69c5c4 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#18 0xfd69ced8 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#19 0xff21190c in KstChangeNptsDialogI::applyNptsChange () from /S/KDE/Vdev/lib/libkstapp.so.1
#20 0xff212290 in KstChangeNptsDialogI::qt_invoke () from /S/KDE/Vdev/lib/libkstapp.so.1
#21 0xfd69c5c4 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#22 0xfd69ced8 in QObject::activate_signal () from /usr/local/kde/lib/libqt-mt.so.3
#23 0xfd6d1840 in QWidget::event () from /usr/local/kde/lib/libqt-mt.so.3
#24 0xfd643024 in QApplication::internalNotify () from /usr/local/kde/lib/libqt-mt.so.3
#25 0xfd6433b4 in QApplication::notify () from /usr/local/kde/lib/libqt-mt.so.3
#26 0xfe0bd6d0 in KApplication::notify () from /usr/local/kde/V3.4.0/lib/libkdecore.so.4
#27 0xfd5e1e78 in QETWidget::translateMouseEvent () from /usr/local/kde/lib/libqt-mt.so.3
#28 0xfd5e0210 in QApplication::x11ProcessEvent () from /usr/local/kde/lib/libqt-mt.so.3
#29 0xfd5f1f64 in QEventLoop::processEvents () from /usr/local/kde/lib/libqt-mt.so.3
#30 0xfd658e7c in QEventLoop::enterLoop () from /usr/local/kde/lib/libqt-mt.so.3
#31 0xfd658d64 in QEventLoop::exec () from /usr/local/kde/lib/libqt-mt.so.3
#32 0xfd641fb8 in QApplication::exec () from /usr/local/kde/lib/libqt-mt.so.3
#33 0x0001bfb0 in main ()
Comment 3 George Staikos 2005-12-20 16:39:54 UTC
SVN commit 490040 by staikos:

Does this help?  I still can't reproduce it so I'm guessing.
CCBUG: 118696


 M  +4 -3      kstchangenptsdialog_i.cpp  


--- trunk/extragear/graphics/kst/kst/kstchangenptsdialog_i.cpp #490039:490040
@@ -175,10 +175,11 @@
     if (CurveList->isSelected(i)) {
       KstRVectorPtr vector = rvl[i]; // FIXME: broken
       vector->readLock();
-      vector->dataSource()->readLock();
-      supportsTime = vector->dataSource()->supportsTimeConversions();
-      vector->dataSource()->readUnlock();
+      KstDataSourcePtr ds = vector->dataSource();
       vector->readUnlock();
+      ds->readLock();
+      supportsTime = ds->supportsTimeConversions();
+      ds->readUnlock();
       if (!supportsTime) {
         break;
       }
Comment 4 George Staikos 2005-12-20 17:02:40 UTC
I used the NetCDF source for my tests (and was unable to reproduce it).
Comment 5 Nicolas Brisset 2005-12-20 17:50:44 UTC
No :-( It still freezes !
I'm surprised you don't see it, as it happens ca 90% of the time here.
Comment 6 Nicolas Brisset 2006-01-26 14:01:57 UTC
Well, somehow I can't reproduce this any longer, so I'll close it. It must have been fixed somehow :-)