Bug 390865 - Sometimes Crash When Performing Curve Fitting
Summary: Sometimes Crash When Performing Curve Fitting
Status: RESOLVED FIXED
Alias: None
Product: LabPlot2
Classification: Applications
Component: general (show other bugs)
Version: 2.4.0
Platform: Neon Linux
: NOR crash
Target Milestone: ---
Assignee: Stefan Gerlach
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2018-02-21 20:01 UTC by Colin Griffith
Modified: 2018-03-04 11:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
cone_fundamentals (489.68 KB, image/png)
2018-02-24 09:10 UTC, Alexander Semke
Details
Fitted Curves in Labplot2 (73.38 KB, image/png)
2018-02-25 02:52 UTC, Colin Griffith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Griffith 2018-02-21 20:01:28 UTC
Application: labplot2 (2.4.0)

Qt Version: 5.9.3
Frameworks Version: 5.43.0
Operating System: Linux 4.13.0-32-generic x86_64
Distribution: KDE neon User Edition 5.12

-- Information about the crash:
I was repeatedly performing curve fitting with multi-peak Gaussian curves. The algorithm for determining best fit doesn't work very well, so I have to manually adjust values to be sorta close and then it seems to work.

Sometimes, however, it just crashes when I finish editing the curve parameters and apply them. I sadly cannot remember now if it crashed when I hit 'Apply', or if it crashed when I clicked the button to recalculate the curves.

There are a number of oddities to the version of Labplot2 in the Neon repositories, though. It reports itself as version 2.4, but has a feature that the website claims will be new in 2.5 (setting lower/upper limits on curve fitting parameters).

I am using the 'User Edition' of KDE Neon, installed somewhat shortly before Plasma 5.12 was released. I remember people saying that the LTS User Edition got the 5.12 update sooner than the 'regular' User Edition, but now there is only a single User Edition on the website - so I do not know how relevant this information might be.

The crash can be reproduced sometimes.

-- Backtrace:
Application: labplot2 (labplot2), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f0dcb13e940 (LWP 3464))]

Thread 9 (Thread 0x7f0d9506f700 (LWP 3474)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d9506f700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7f0d95870700 (LWP 3473)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d95870700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 7 (Thread 0x7f0d96071700 (LWP 3472)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d96071700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7f0d96872700 (LWP 3471)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d96872700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7f0d97073700 (LWP 3470)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d97073700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7f0d97874700 (LWP 3469)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d97874700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7f0d987dd700 (LWP 3468)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0d987dd700) at pthread_create.c:333
#4  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f0da71a6700 (LWP 3467)):
#0  0x00007f0dc23fc74d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f0dbbffd38c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f0dbbffd49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f0dc32426cb in QEventDispatcherGlib::processEvents (this=0x7f0da00008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x00007f0dc31eae2a in QEventLoop::exec (this=this@entry=0x7f0da71a5c50, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x00007f0dc30138f4 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:515
#6  0x00007f0dbf989315 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007f0dc3018709 in QThreadPrivate::start (arg=0x7f0dbfbfdd40) at thread/qthread_unix.cpp:368
#8  0x00007f0dbf1bf6ba in start_thread (arg=0x7f0da71a6700) at pthread_create.c:333
#9  0x00007f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f0dcb13e940 (LWP 3464)):
[KCrash Handler]
#6  CartesianPlot::xMin (this=0x0) at /workspace/build/src/backend/worksheet/plots/cartesian/CartesianPlot.cpp:514
#7  0x000000000071b25e in AxisPrivate::retransformTickLabelPositions (this=this@entry=0x86cf560) at /workspace/build/src/backend/worksheet/plots/cartesian/Axis.cpp:1484
#8  0x000000000071b815 in AxisPrivate::retransformTickLabelStrings (this=0x86cf560) at /workspace/build/src/backend/worksheet/plots/cartesian/Axis.cpp:1400
#9  0x0000000000723005 in AxisSetLabelsAutoPrecisionCmd::finalize (this=0x13a2b5e0) at /workspace/build/src/backend/worksheet/plots/cartesian/Axis.cpp:712
#10 0x00007f0dc42b5963 in QUndoStack::push (this=0x1db6d90, cmd=cmd@entry=0x13a2b5e0) at util/qundostack.cpp:639
#11 0x00000000006631d0 in AbstractAspect::exec (this=0x139df850, cmd=0x13a2b5e0) at /workspace/build/src/backend/core/AbstractAspect.cpp:638
#12 0x0000000000710050 in Axis::setLabelsAutoPrecision (this=0x139df850, labelsAutoPrecision=<optimized out>) at /workspace/build/src/backend/worksheet/plots/cartesian/Axis.cpp:716
#13 0x000000000058551e in AxisDock::labelsAutoPrecisionChanged (this=<optimized out>, state=0) at /workspace/build/src/kdefrontend/dockwidgets/AxisDock.cpp:1127
#14 0x00007f0dc3219279 in QMetaObject::activate (sender=0xde540b0, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe3d188c10) at kernel/qobject.cpp:3766
#15 0x00007f0dc3219b87 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7f0dc4624e20 <QCheckBox::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe3d188c10) at kernel/qobject.cpp:3628
#16 0x00007f0dc4052f4e in QCheckBox::stateChanged (this=<optimized out>, _t1=0) at .moc/moc_qcheckbox.cpp:167
#17 0x00007f0dc4045210 in QAbstractButtonPrivate::click (this=0xde540f0) at widgets/qabstractbutton.cpp:397
#18 0x00007f0dc4045344 in QAbstractButton::mouseReleaseEvent (this=0xde540b0, e=0x7ffe3d1890a0) at widgets/qabstractbutton.cpp:1010
#19 0x00007f0dc3f89b08 in QWidget::event (this=0xde540b0, event=0x7ffe3d1890a0) at kernel/qwidget.cpp:9200
#20 0x00007f0dc3f4ab9c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0xde540b0, e=0x7ffe3d1890a0) at kernel/qapplication.cpp:3722
#21 0x00007f0dc3f531cb in QApplication::notify (this=<optimized out>, receiver=0xde540b0, e=0x7ffe3d1890a0) at kernel/qapplication.cpp:3198
#22 0x00007f0dc31ecdf8 in QCoreApplication::notifyInternal2 (receiver=receiver@entry=0xde540b0, event=event@entry=0x7ffe3d1890a0) at kernel/qcoreapplication.cpp:1018
#23 0x00007f0dc3f51b6f in QCoreApplication::sendEvent (event=<optimized out>, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:233
#24 QApplicationPrivate::sendMouseEvent (receiver=receiver@entry=0xde540b0, event=event@entry=0x7ffe3d1890a0, alienWidget=alienWidget@entry=0xde540b0, nativeWidget=0x1da2440, buttonDown=buttonDown@entry=0x7f0dc464c820 <qt_button_down>, lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:2704
#25 0x00007f0dc3fa3b06 in QWidgetWindow::handleMouseEvent (this=this@entry=0x1f4f260, event=event@entry=0x7ffe3d1894a0) at kernel/qwidgetwindow.cpp:622
#26 0x00007f0dc3fa6563 in QWidgetWindow::event (this=0x1f4f260, event=0x7ffe3d1894a0) at kernel/qwidgetwindow.cpp:243
#27 0x00007f0dc3f4ab9c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x1f4f260, e=0x7ffe3d1894a0) at kernel/qapplication.cpp:3722
#28 0x00007f0dc3f525a7 in QApplication::notify (this=0x7ffe3d189980, receiver=0x1f4f260, e=0x7ffe3d1894a0) at kernel/qapplication.cpp:3481
#29 0x00007f0dc31ecdf8 in QCoreApplication::notifyInternal2 (receiver=receiver@entry=0x1f4f260, event=event@entry=0x7ffe3d1894a0) at kernel/qcoreapplication.cpp:1018
#30 0x00007f0dc37dc230 in QCoreApplication::sendSpontaneousEvent (event=0x7ffe3d1894a0, receiver=0x1f4f260) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#31 QGuiApplicationPrivate::processMouseEvent (e=0x13b5c3b0) at kernel/qguiapplication.cpp:1949
#32 0x00007f0dc37de195 in QGuiApplicationPrivate::processWindowSystemEvent (e=e@entry=0x13b5c3b0) at kernel/qguiapplication.cpp:1733
#33 0x00007f0dc37b77cb in QWindowSystemInterface::sendWindowSystemEvents (flags=...) at kernel/qwindowsysteminterface.cpp:939
#34 0x00007f0daf817470 in userEventSourceDispatch (source=<optimized out>) at qeventdispatcher_glib.cpp:77
#35 0x00007f0dbbffd197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#36 0x00007f0dbbffd3f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#37 0x00007f0dbbffd49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#38 0x00007f0dc32426af in QEventDispatcherGlib::processEvents (this=0x1d16180, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#39 0x00007f0dc31eae2a in QEventLoop::exec (this=this@entry=0x7ffe3d189850, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#40 0x00007f0dc31f3d64 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1291
#41 0x00007f0dc37d3bdc in QGuiApplication::exec () at kernel/qguiapplication.cpp:1679
#42 0x00007f0dc3f4aaf5 in QApplication::exec () at kernel/qapplication.cpp:2910
#43 0x00000000005545f7 in main (argc=1, argv=<optimized out>) at /workspace/build/src/kdefrontend/LabPlot.cpp:108

The reporter indicates this bug may be a duplicate of or related to bug 376509.

Reported using DrKonqi
Comment 1 Alexander Semke 2018-02-22 07:09:11 UTC
(In reply to Colin Griffith from comment #0)
> Application: labplot2 (2.4.0)
> 
> Qt Version: 5.9.3
> Frameworks Version: 5.43.0
> Operating System: Linux 4.13.0-32-generic x86_64
> Distribution: KDE neon User Edition 5.12
> 
> -- Information about the crash:
> I was repeatedly performing curve fitting with multi-peak Gaussian curves.
> The algorithm for determining best fit doesn't work very well, so I have to
> manually adjust values to be sorta close and then it seems to work.
> 
> Sometimes, however, it just crashes when I finish editing the curve
> parameters and apply them. I sadly cannot remember now if it crashed when I
> hit 'Apply', or if it crashed when I clicked the button to recalculate the
> curves.
The call stack you attached indicates that you changed the "auto precision" options in the properties widget for an axis. This part was reworked a bit recently and should be safe already.

> 
> There are a number of oddities to the version of Labplot2 in the Neon
> repositories, though. It reports itself as version 2.4, but has a feature
> that the website claims will be new in 2.5 (setting lower/upper limits on
> curve fitting parameters).
We changed the version a bit late during the development of 2.5. Looks like Neon picked out the code of 2.5 in development but with the version still set to 2.4. The current code in the repository has the version set to 2.5 - we're preparing the next release right now. Does Neon provides a more recent version of LabPlot or do you have any chance to compile it from sources? The fitting functionality was greatly extended for 2.5 and any kind of feedback and additional testing would be great here. Thanks!
Comment 2 Colin Griffith 2018-02-22 08:14:38 UTC
(In reply to Alexander Semke from comment #1)
> (In reply to Colin Griffith from comment #0)
> > Application: labplot2 (2.4.0)
> > 
> > Qt Version: 5.9.3
> > Frameworks Version: 5.43.0
> > Operating System: Linux 4.13.0-32-generic x86_64
> > Distribution: KDE neon User Edition 5.12
> > 
> > -- Information about the crash:
> > I was repeatedly performing curve fitting with multi-peak Gaussian curves.
> > The algorithm for determining best fit doesn't work very well, so I have to
> > manually adjust values to be sorta close and then it seems to work.
> > 
> > Sometimes, however, it just crashes when I finish editing the curve
> > parameters and apply them. I sadly cannot remember now if it crashed when I
> > hit 'Apply', or if it crashed when I clicked the button to recalculate the
> > curves.
> The call stack you attached indicates that you changed the "auto precision"
> options in the properties widget for an axis. This part was reworked a bit
> recently and should be safe already.
> 
> > 
> > There are a number of oddities to the version of Labplot2 in the Neon
> > repositories, though. It reports itself as version 2.4, but has a feature
> > that the website claims will be new in 2.5 (setting lower/upper limits on
> > curve fitting parameters).
> We changed the version a bit late during the development of 2.5. Looks like
> Neon picked out the code of 2.5 in development but with the version still
> set to 2.4. The current code in the repository has the version set to 2.5 -
> we're preparing the next release right now. Does Neon provides a more recent
> version of LabPlot or do you have any chance to compile it from sources? The
> fitting functionality was greatly extended for 2.5 and any kind of feedback
> and additional testing would be great here. Thanks!

As far as I'm aware, I'm on the latest version of Labplot that KDE Neon has packages for. I paused while typing this just to double check, and indeed there are no new updates.

I don't think I have all the packages necessary to compile Labplot, but I can probably try installing them and doing so. The 'INSTALL' file seems to include all the info I'll need for that :)

It's getting rather late, so I'll probably do this tomorrow morning. Glad to know the odd package version isn't MY fault :) Hopefully this is why CAS worksheets are broken too... But that'd be a completely different bug report.
Comment 3 Alexander Semke 2018-02-23 09:06:40 UTC
(In reply to Colin Griffith from comment #2)
> I don't think I have all the packages necessary to compile Labplot, but I
> can probably try installing them and doing so. The 'INSTALL' file seems to
> include all the info I'll need for that :)
Yes, once the dependencies are installed it should be pretty straight-forward to compile LabPlot. Don't forget to do 'make install' in the build folder. If you have any problems or questions, please reach out to us.
Comment 4 Colin Griffith 2018-02-23 20:36:23 UTC
(In reply to Alexander Semke from comment #3)
> (In reply to Colin Griffith from comment #2)
> > I don't think I have all the packages necessary to compile Labplot, but I
> > can probably try installing them and doing so. The 'INSTALL' file seems to
> > include all the info I'll need for that :)
> Yes, once the dependencies are installed it should be pretty
> straight-forward to compile LabPlot. Don't forget to do 'make install' in
> the build folder. If you have any problems or questions, please reach out to
> us.

I have it compiled, but it isn't being picked up by DrKonqi when it crashes. Repeating a crash is rather difficult, so I just have to mess around with it until it happens again.

I have it installed into a directory in my home folder, with $PATH and $XDG_DATA_DIRS modified to reflect the location. Specifically, I have this in my .profile:

    PATH="/home/tynach/Software/compiled/bin:$PATH"
    XDG_DATA_DIRS="/home/tynach/Software/compiled/share:$XDG_DATA_DIRS"

Without modifying $XDG_DATA_DIRS, the program would mostly run but crash more frequently (and complain about files missing on startup; honestly, the warning that popped up is what led me to knowing that I needed to to begin with, and I was very appreciative of that).

I suppose now I should compile it using /usr as the installation prefix, and uninstall the version of Labplot from the repositories... Or do you have a different recommendation?
Comment 5 Colin Griffith 2018-02-23 20:48:37 UTC
In case it's relevant, I suppose I should mention that the data I'm messing with is 4401 data points, with X values ranging from 390 to 830, and Y values ranging from 0 to 2. Most plots have 3 data sets plotted, and one fitting curve for each (so 3 total fitting curves, and 6 curves total). Usually I have 2 such data sets, and so 2 plots, making 12 curves total.

The exact data can be downloaded from these pages:
http://www.cvrl.org/ciepr8dp.htm
http://www.cvrl.org/ciexyzpr.htm


To get the exact data files I'm using, choose these options on the form:

1st page: 2-degree cone fundamentals in Energy (linear) units with a stepsize of 0.1nm, in CSV format.

2nd page: 2-degree XYZ color matching functions with a stepsize of 0.1nm, in CSV format.
Comment 6 Alexander Semke 2018-02-24 09:05:24 UTC
(In reply to Colin Griffith from comment #4)
> I suppose now I should compile it using /usr as the installation prefix, and
> uninstall the version of Labplot from the repositories... Or do you have a
> different recommendation?
Yes, it's better to uninstall the version provided by the distribution first and install the version compiled from the sources. With this we shouldn't mess up anymore with the different locations of files used by the application.

Also, to get a readable debug output please compile in the debug-mode. For this, simple use our compile_debug script:
1. ./compile_debug/
2. cd build_debug
2. sudo make install

Ater this LabPlot should run without problems and the message at startup complaining about the missing configuration file should be gone.
Comment 7 Alexander Semke 2018-02-24 09:10:16 UTC
(In reply to Colin Griffith from comment #5)
> In case it's relevant, I suppose I should mention that the data I'm messing
> with is 4401 data points, with X values ranging from 390 to 830, and Y
> values ranging from 0 to 2. Most plots have 3 data sets plotted, and one
> fitting curve for each (so 3 total fitting curves, and 6 curves total).
> Usually I have 2 such data sets, and so 2 plots, making 12 curves total.
> 
> The exact data can be downloaded from these pages:
> http://www.cvrl.org/ciepr8dp.htm
> http://www.cvrl.org/ciexyzpr.htm
> 
> 
> To get the exact data files I'm using, choose these options on the form:
> 
> 1st page: 2-degree cone fundamentals in Energy (linear) units with a
> stepsize of 0.1nm, in CSV format.
> 
> 2nd page: 2-degree XYZ color matching functions with a stepsize of 0.1nm, in
> CSV format.

I just tried out the data from the first page. I have no problems to plot and to fit to those three Gauss curves. I attached the screenshot of the results. The curves with the filled areas are the fitted results.

To get this data quickly fitted in LabPlot:
1. import the csv file into a spreadsheet, use preview tab to check the results of the import settings
2. do a right click in the spreadsheet and select "Plot data" from the context menu and plot three curves in one single plot
3. do a right click on the curve (either in the plot or in the project explorer) and select Analysis/Fit/Gauss from the context menu
4. we fail to guess good starting values at the moment, so just provide a reasonable mean value for \mu and recalcute again.
Comment 8 Alexander Semke 2018-02-24 09:10:44 UTC
Created attachment 110959 [details]
cone_fundamentals
Comment 9 Alexander Semke 2018-02-24 09:18:36 UTC
(In reply to Alexander Semke from comment #6)
> 1. ./compile_debug/
> 2. cd build_debug
> 2. sudo make install
It should be ./compile_debug here, of course.
Comment 10 Colin Griffith 2018-02-25 02:51:00 UTC
(In reply to Alexander Semke from comment #7)
> (In reply to Colin Griffith from comment #5)
> > In case it's relevant, I suppose I should mention that the data I'm messing
> > with is 4401 data points, with X values ranging from 390 to 830, and Y
> > values ranging from 0 to 2. Most plots have 3 data sets plotted, and one
> > fitting curve for each (so 3 total fitting curves, and 6 curves total).
> > Usually I have 2 such data sets, and so 2 plots, making 12 curves total.
> > 
> > The exact data can be downloaded from these pages:
> > http://www.cvrl.org/ciepr8dp.htm
> > http://www.cvrl.org/ciexyzpr.htm
> > 
> > 
> > To get the exact data files I'm using, choose these options on the form:
> > 
> > 1st page: 2-degree cone fundamentals in Energy (linear) units with a
> > stepsize of 0.1nm, in CSV format.
> > 
> > 2nd page: 2-degree XYZ color matching functions with a stepsize of 0.1nm, in
> > CSV format.
> 
> I just tried out the data from the first page. I have no problems to plot
> and to fit to those three Gauss curves. I attached the screenshot of the
> results. The curves with the filled areas are the fitted results.
> 
> To get this data quickly fitted in LabPlot:
> 1. import the csv file into a spreadsheet, use preview tab to check the
> results of the import settings
> 2. do a right click in the spreadsheet and select "Plot data" from the
> context menu and plot three curves in one single plot
> 3. do a right click on the curve (either in the plot or in the project
> explorer) and select Analysis/Fit/Gauss from the context menu
> 4. we fail to guess good starting values at the moment, so just provide a
> reasonable mean value for \mu and recalcute again.

This is consistent with my testing. However, I've been using curves with 3 - 8 peaks, attempting to visually match the fitted curve precisely to the actual data so that without zooming in they appear to be 100% identical.

It is while repeatedly calculating the curves and tweaking the resulting values that the crash occurs, and continues to occur.

I'll attach a screenshot of what I managed to get as far as results go yesterday, but have not been able to get the 'L' curve to fit any better (theoretically I should be able to get it to fit as well as the 'M' curve, but the algorithms refuse to behave rationally in some cases). All three curves are fit with 5 peaks.

Either way, my troubles with fitting the curves are not the topic of this bug, but rather the fact that the program crashes after simply changing some values over and over. I don't believe that should happen.

Also, I had already built Labplot with debugging symbols, but I'm now in the process of rebuilding it for installation in '/usr'.
Comment 11 Colin Griffith 2018-02-25 02:52:52 UTC
Created attachment 110982 [details]
Fitted Curves in Labplot2

Dashed lines are the fitted curves.
Comment 12 Colin Griffith 2018-02-25 06:16:17 UTC
The crash still occurs, and is not picked up by DrKonqi despite being a debug build that was installed to the /usr directory (after purging both the copy installed from the repositories, and the version I had built and installed into my home directory).

Is there another way to obtain a backtrace?
Comment 13 Alexander Semke 2018-02-25 15:05:48 UTC
(In reply to Colin Griffith from comment #12)
> The crash still occurs, and is not picked up by DrKonqi despite being a
> debug build that was installed to the /usr directory (after purging both the
> copy installed from the repositories, and the version I had built and
> installed into my home directory).
> 
> Is there another way to obtain a backtrace?
yes, by executing the application in the debugger:
1. compile labplot with debug symbols
2. gdb path_to_labplot2
3. execute 'run' in gdb
4. execute 'bt' once the application crashed

Alternatively, if you have the steps leading to a crash reproducible on your side, simply describe them and we can try to understand the problem.
Comment 14 Stefan Gerlach 2018-03-04 11:01:24 UTC
The crashes were probably triggered by error handling of GSL. Please try if the latest code still crashes.