[Kst] [Bug 208832] New: Segfault while simultaneously reading and plotting data
Michael Vincent
bug.zilla.vynce at neverbox.com
Tue Sep 29 01:29:01 CEST 2009
https://bugs.kde.org/show_bug.cgi?id=208832
Summary: Segfault while simultaneously reading and plotting
data
Product: kst
Version: 1.8.0
Platform: Fedora RPMs
OS/Version: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: general
AssignedTo: kst at kde.org
ReportedBy: bug.zilla.vynce at neverbox.com
Version: 1.8.0 (using KDE 4.3.1)
Compiler: gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
OS: Linux
Installed from: Fedora RPMs
I have a set of KstScripts that I use for generating different types of plots.
I also have a custom data source plugin. When I initiate Kst via a script to
plot a large data file, it will simultaneously add curves to the plot and read
in chunks of data, which will somehow cause a segfault. The segfault occurs
when KstVector::interpolate() reads from _v at the same time as
KstVector::resize() is zeroing a new section of _v. The reads and writes occur
in different parts of _v. I've included the backtraces for both threads and
relevant code snippets below. I've marked the locations where the segfault
occurs in both code snippets. Note that I copied the GENERATE_INTERPOLATION
macro into the KstVector::interpolate() function so that I could see what was
going on in gdb.
Program received signal SIGSEGV, Segmentation fault.
0x00da84fe in KstVector::interpolate (this=0x866ba28, in_i=7624, ns_i=31206)
at kstvector.cpp:185
Thread 1:
#0 0x00da84fe in KstVector::interpolate (this=0x866ba28, in_i=7624,
ns_i=31206) at kstvector.cpp:185
#1 0x0057d84b in KstVCurve::paint (this=0x883a0d0, context=@0xbfffc9f4)
at kstvcurve.cpp:1475
#2 0x002cabc4 in Kst2DPlot::draw (this=0x88720b0, p=@0xbfffcd20)
at kst2dplot.cpp:2902
#3 0x002cb3f6 in Kst2DPlot::draw (this=0x88720b0) at kst2dplot.cpp:2737
#4 0x002cb4cc in Kst2DPlot::updateSelf (this=0x88720b0) at kst2dplot.cpp:2661
#5 0x00312935 in KstViewObject::paintUpdate (this=0x88720b0)
at kstviewobject.cpp:426
#6 0x00315887 in KstViewObject::paint (this=0x88720b0, p=@0xbfffd028,
bounds=@0xbfffcfc8) at kstviewobject.cpp:340
#7 0x00315b94 in KstViewObject::paint (this=0x865d3c8, p=@0xbfffd028,
bounds=@0xbfffd198) at kstviewobject.cpp:373
#8 0x003340af in KstTopLevelView::paint (this=0x865d3c8, p=@0xbfffd028,
bounds=@0xbfffd198) at ksttoplevelview.cpp:190
#9 0x0032b35f in KstTopLevelView::paint (this=0x865d3c8,
type=KstPainter::P_PAINT, bounds=@0xbfffd198) at ksttoplevelview.cpp:209
#10 0x0032b492 in KstTopLevelView::paint (this=0x865d3c8,
type=KstPainter::P_PAINT) at ksttoplevelview.cpp:199
#11 0x0042c239 in KstApp::paintAll (this=0x80bb308, pt=KstPainter::P_PAINT)
at kst.cpp:1970
#12 0x011f8e62 in KstBindCurveCollection::append (this=0xb7000d70,
exec=0xbfffd778, args=@0xbfffd374) at bind_curvecollection.cpp:155
#13 0x011f318e in KstBindCollection::call (this=0x891c678, exec=0xbfffd778,
self=@0xbfffd380, args=@0xbfffd374) at bind_collection.cpp:116
#14 0x0139dcb9 in KJS::Object::call (this=0xbfffd398, exec=0xbfffd778,
thisObj=@0xbfffd380, args=@0xbfffd374) at object.cpp:73
#15 0x013b7593 in KJS::FunctionCallNode::evaluate (this=0x8288d58,
exec=0xbfffd778) at nodes.cpp:870
#16 0x013b5006 in KJS::ExprStatementNode::execute (this=0x84e5700,
exec=0xbfffd778) at nodes.cpp:1980
#17 0x013b3638 in KJS::SourceElementsNode::execute (this=0x84edc88,
exec=0xbfffd778) at nodes.cpp:3114
#18 0x013ae7a9 in KJS::BlockNode::execute (this=0x8375648, exec=0xbfffd778)
at nodes.cpp:1942
#19 0x013b410c in KJS::ForNode::execute (this=0x8375678, exec=0xbfffd778)
at nodes.cpp:2199
#20 0x013b3638 in KJS::SourceElementsNode::execute (this=0x85fcdf8,
exec=0xbfffd778) at nodes.cpp:3114
#21 0x013ae7a9 in KJS::BlockNode::execute (this=0x837ada0, exec=0xbfffd778)
at nodes.cpp:1942
#22 0x013b7f9d in KJS::InterpreterImp::evaluate (this=0x831f3e0,
code=@0xbfffd834, thisV=@0xbfffd838) at internal.cpp:904
#23 0x013b837a in KJS::Interpreter::evaluate (this=0x84ba008,
code=@0xbfffd834, thisV=@0xbfffd838) at interpreter.cpp:166
#24 0x01277227 in KJSEmbed::KJSEmbedPart::execute (this=0x82793a0,
result=@0x8279434, script=@0xbfffd888, self=@0xbfffd90c)
at kjsembedpart.cpp:262
#25 0x0127576c in KJSEmbed::KJSEmbedPart::execute (this=0x82793a0,
script=@0xbfffd888, self=@0xbfffd90c) at kjsembedpart.cpp:256
#26 0x01278499 in KJSEmbed::KJSEmbedPart::runFile (this=0x82793a0,
name=@0xbfffd91c, self=@0xbfffd90c) at kjsembedpart.cpp:294
#27 0x011cb021 in KstBindKst::loadScript (this=0x8663778, exec=0xbfffdc98,
args=@0xbfffda14) at bind_kst.cpp:207
#28 0x011ca47e in KstBindKst::call (this=0x86637e8, exec=0xbfffdc98,
self=@0xbfffda20, args=@0xbfffda14) at bind_kst.cpp:182
#29 0x0139dcb9 in KJS::Object::call (this=0xbfffda38, exec=0xbfffdc98,
thisObj=@0xbfffda20, args=@0xbfffda14) at object.cpp:73
#30 0x013b7593 in KJS::FunctionCallNode::evaluate (this=0x8482778,
exec=0xbfffdc98) at nodes.cpp:870
#31 0x013b5006 in KJS::ExprStatementNode::execute (this=0x815b8c8,
exec=0xbfffdc98) at nodes.cpp:1980
#32 0x013b3638 in KJS::SourceElementsNode::execute (this=0x815c150,
exec=0xbfffdc98) at nodes.cpp:3114
#33 0x013ae7a9 in KJS::BlockNode::execute (this=0x83a7778, exec=0xbfffdc98)
at nodes.cpp:1942
#34 0x013b7f9d in KJS::InterpreterImp::evaluate (this=0x831f3e0,
code=@0xbfffdd54, thisV=@0xbfffdd58) at internal.cpp:904
#35 0x013b837a in KJS::Interpreter::evaluate (this=0x84ba008,
code=@0xbfffdd54, thisV=@0xbfffdd58) at interpreter.cpp:166
#36 0x01277227 in KJSEmbed::KJSEmbedPart::execute (this=0x82793a0,
result=@0xbfffdda8, script=@0xbfffde84, self=@0xbfffdde0)
at kjsembedpart.cpp:262
#37 0x011aefd3 in JSIfaceImpl::evaluate (this=0x82f4398, script=@0xbfffde84)
at jsiface_impl.cpp:50
#38 0x012736ad in JSIface::process (this=0x82f4398, fun=@0xbfffe0e4,
data=@0xbfffe0dc, replyType=@0xbfffe0d4, replyData=@0xbfffe0cc)
at jsiface_skel.cpp:33
#39 0x00855f8e in DCOPClient::receive (this=0x809c5b0, objId=@0xbfffe0ec,
fun=@0xbfffe0e4, data=@0xbfffe0dc, replyType=@0xbfffe0d4,
replyData=@0xbfffe0cc) at dcopclient.cpp:1643
#40 0x0085b3d1 in DCOPProcessInternal (d=0x80a6098, opcode=2, key=52,
dataReceived=@0xbfffe1c0, canPost=true) at dcopclient.cpp:520
#41 0x0085be2a in DCOPProcessMessage (iceConn=0x80a20e0,
clientObject=0x80a6098, opcode=2, length=544, replyWait=0x0,
replyWaitRet=0xbfffe214) at dcopclient.cpp:432
#42 0x00868e14 in KDE_IceProcessMessages (iceConn=0x80a20e0, replyWait=0x0,
replyReadyRet=0x0) at process.c:326
#43 0x0084c6df in DCOPClient::processSocketData (this=0x809c5b0, fd=12)
at dcopclient.cpp:2014
#44 0x0085bb34 in DCOPClient::qt_invoke (this=0x809c5b0, _id=2, _o=0xbfffe36c)
at ./dcopclient.moc:176
#45 0x022b0e4a in QObject::activate_signal (this=0x809c158, clist=0x80a0570,
o=0xbfffe36c) at kernel/qobject.cpp:2359
#46 0x022b2c43 in QObject::activate_signal (this=0x809c158, signal=2, param=12)
at kernel/qobject.cpp:2452
#47 0x0264a6c0 in QSocketNotifier::activated (this=0x809c158, t0=12)
at .moc/release-shared-mt/moc_qsocketnotifier.cpp:85
#48 0x022d3267 in QSocketNotifier::event (this=0x809c158, e=0xbfffe6a8)
at kernel/qsocketnotifier.cpp:261
#49 0x02247f75 in QApplication::internalNotify (this=0xbffff170,
receiver=0x809c158, e=0xbfffe6a8) at kernel/qapplication.cpp:2638
#50 0x022490c6 in QApplication::notify (this=0xbffff170, receiver=0x809c158,
e=0xbfffe6a8) at kernel/qapplication.cpp:2375
#51 0x02bf1262 in KApplication::notify (this=0xbffff170, receiver=0x809c158,
event=0xbfffe6a8) at kapplication.cpp:550
#52 0x0223b961 in QApplication::sendEvent () at kernel/qapplication.h:523
#53 QEventLoop::activateSocketNotifiers (this=0x80992f0)
at kernel/qeventloop_unix.cpp:581
#54 0x021f0aa3 in QEventLoop::processEvents (this=0x80992f0, flags=4)
at kernel/qeventloop_x11.cpp:386
#55 0x02262630 in QEventLoop::enterLoop (this=0x80992f0)
at kernel/qeventloop.cpp:201
#56 0x022624f6 in QEventLoop::exec (this=0x80992f0)
at kernel/qeventloop.cpp:148
#57 0x0224864f in QApplication::exec (this=0xbffff170)
at kernel/qapplication.cpp:2761
#58 0x080539eb in main (argc=1, argv=0xbffff2f4) at main.cpp:854
double KstVector::interpolate(int in_i, int ns_i) const {
assert(_size > 0);
/** Limits checks - optional? **/
if (in_i < 0 || _size == 1) {
return _v[0];
}
if (in_i >= ns_i - 1) {
return _v[_size - 1];
}
/** speedup check **/
if (ns_i == _size) { /* no extrapolating or decimating needed */
return _v[in_i]; /* Thread 1 segfaults here */
}
double fj = in_i * double(_size - 1) / double(ns_i-1); /* scaled index */
int j = int(floor(fj)); /* index of sample one lower */
assert(j+1 < _size && j >= 0);
if (_v[j + 1] != _v[j + 1] || _v[j] != _v[j]) {
return KST::NOPOINT;
}
double fdj = fj - float(j); /* fdj is fraction between _v[j] and _v[j+1] */
return _v[j + 1] * fdj + _v[j] * (1.0 - fdj);
}
Thread 2:
#0 0x00da9b10 in KstVector::resize (this=0x866ba28, sz=46809, reinit=true)
at kstvector.cpp:464
#1 0x00db2d5d in KstRVector::doUpdate (this=0x866ba28, force=false)
at kstrvector.cpp:629
#2 0x00db33fc in KstRVector::update (this=0x866ba28, update_counter=25)
at kstrvector.cpp:459
#3 0x00579d42 in KstVCurve::update (this=0x866fb08, update_counter=25)
at kstvcurve.cpp:249
#4 0x003b7642 in UpdateThread::doUpdates (this=0x858fdf0, force=false,
gotData=0xb7b1633b) at updatethread.cpp:212
#5 0x003b8e47 in UpdateThread::run (this=0x858fdf0) at updatethread.cpp:114
#6 0x022414bc in QThreadInstance::start (_arg=0x859176c)
at kernel/qthread_unix.cpp:122
#7 0x00ae851f in start_thread (arg=0xb7b16b90) at pthread_create.c:297
#8 0x00eb604e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
bool KstVector::resize(int sz, bool reinit) {
if (sz > 0) {
_v = static_cast<double*>(KST::realloc(_v, sz*sizeof(double)));
if (!_v) {
return false;
}
#ifdef ZERO_MEMORY
if (reinit && _size < sz) {
for (int i = _size; i < sz; i++) {
_v[i] = KST::NOPOINT; /* Thread 2 is concurrently at this point */
}
}
#endif
_size = sz;
updateScalars();
}
setDirty();
return true;
}
After some serious digging, the segfault actually appears to be some kind of
floating point exception that doesn't get handled properly (or something along
those lines).
This is the instruction that causes the SIGSEGV:
fldl 0x8(%edx,%ecx,8)
And here's the status of the FPU when the segfault occurs:
(gdb) info float
R7: Empty 0x4006e500000000000000
R6: Empty 0x3ffe8000000000000000
R5: Empty 0x40088b14e3d6180c0000
R4: Empty 0x00000000000000000000
R3: Empty 0x40069f00000000000000
R2: Empty 0x00000000000000000000
R1: Empty 0x00000000000000000000
=>R0: Empty 0x00000000000000000000
Status Word: 0x0023 IE DE PE
TOP: 0
Control Word: 0x037f IM DM ZM OM UM PM
PC: Extended Precision (64-bits)
RC: Round to nearest
Tag Word: 0xffff
Instruction Pointer: 0x73:0x00170755
Operand Pointer: 0x7b:0xbfffc784
Opcode: 0xdb9d
I haven't tried recompiling the kernel yet with printk's in the floating point
exception code to see if I can figure out what's really going on. I fixed the
problem with a somewhat brute force approach by adding a mutex to the two
functions.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Kst
mailing list