| Summary: | Digikam crashes while histogram computation | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Geert Janssens <info> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | afsanchez93, ahepas1999, andriy155, caulier.gilles, kchak79, kde.uat, kenjarvis, laarriola, leamsi.setroc, marcel.wiesweg, mikael.salson, Rudolf.Leitgeb, schwaba, u.almasov |
| Priority: | NOR | ||
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/digikam/37a1414726f92a3ef3b350a7ff5a939c88d27307 | Version Fixed In: | 3.0.0 |
| Sentry Crash Report: | |||
| Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi |
||
|
Description
Geert Janssens
2011-05-30 22:50:01 UTC
It crash in histogram computation. do you show it from right sidebar ? It still reproducible with a similar backtrace ? Gilles Caulier *** Bug 275299 has been marked as a duplicate of this bug. *** While I have caused digikam to crash several times in a couple of days, I can't determine which action of mine actually triggers this. When I actively try to reproduce I can go jumping through images with or without the histogram visible seemingly forever sometimes, and at other times it crashes 3 times in a row. If there is anything else I can add, just let me know. Would be very interesting if you can reproduce with a 2.0 version. I remember some other crash reports at this location. *** Bug 275559 has been marked as a duplicate of this bug. *** We need feedback using a recent version. 2.0.0 RC is out, please test... Thanks in advance Gilles Caulier Bug 278748 is from 2.0.0. *** Bug 278748 has been marked as a duplicate of this bug. *** *** Bug 280239 has been marked as a duplicate of this bug. *** Anyone who is compiling from current git who can reproduce the crash? *** Bug 284528 has been marked as a duplicate of this bug. *** Marcel, Look like with #284528, the problem still reproducible with 2.2.0... Gilles Caulier I believe there is a problem, but I cannot reproduce. The histogram is computed on data passed via pointer without reference counting, so in principle it is susceptible to data deleted out-of thread and accessed by pointer. But it does not usually happen for most of us, so we do not find out where the deletion happens. Can anyone reproduce the problem running digikam under valgrind? Valgrind usually outputs the code line where a memory area, if accessed invalidly, was deleted. digiKam 2.2.0 is out since few weeks. Crash still valid with this version ? Gilles Caulier *** This bug has been marked as a duplicate of bug 285849 *** *** Bug 285849 has been marked as a duplicate of this bug. *** Created attachment 65491 [details]
New crash information added by DrKonqi
digikam (2.1.1) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4
- What I was doing when the application crashed:
Again, resized the crop area. It's probably exactly the same cause as the last crash I reported but I hope this crash dump sheds more light at the cause.
-- Backtrace (Reduced):
#6 Digikam::ImageHistogram::calculateInThread (this=0x0) at /build/buildd/digikam-2.1.1/core/libs/dimg/filters/levels/imagehistogram.cpp:143
#7 0x00007fc920c25566 in Digikam::HistogramWidget::updateSelectionData (this=<optimized out>, s_data=<optimized out>, s_w=<optimized out>, s_h=<optimized out>, i_sixteenBits=<optimized out>, showProgress=<optimized out>) at /build/buildd/digikam-2.1.1/core/libs/dimg/filters/levels/histogramwidget.cpp:260
#8 0x00007fc920dd3cd9 in Digikam::ImagePropertiesColorsTab::setSelection (this=0x304f260, selectionArea=<optimized out>) at /build/buildd/digikam-2.1.1/core/libs/imageproperties/imagepropertiescolorstab.cpp:543
#9 0x00007fc920dc46d7 in Digikam::ImagePropertiesSideBar::qt_metacall (this=0x2fe4140, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fff37296c60) at /build/buildd/digikam-2.1.1/obj-x86_64-linux-gnu/core/digikam/imagepropertiessidebar.moc:77
#10 0x000000000049c360 in Digikam::ImagePropertiesSideBarDB::qt_metacall (this=0x2fe4140, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fff37296c60) at /build/buildd/digikam-2.1.1/obj-x86_64-linux-gnu/core/digikam/imagepropertiessidebardb.moc:99
*** Bug 286840 has been marked as a duplicate of this bug. *** Git commit fe3583f0a282f025cdda127405e6cfffb45fc28b by Gilles Caulier. Committed on 21/11/2011 at 10:44. Pushed by cgilles into branch 'master'. add more histogram data null pointer checks to pevent chrash in suspected race conditions. CCBUGS: 274555 M +20 -4 libs/dimg/filters/levels/histogramwidget.cpp http://commits.kde.org/digikam/fe3583f0a282f025cdda127405e6cfffb45fc28b Hi all, With #19, i consolidate ImageHistogram data pointer handling to prevent crash. As i connot reproduce the crash on my computers, someone can try to see if problem is reproducible with current implementation from git/master (next 2.4.0 release) ? Thanks in advance Gilles Caulier As described here:
https://bugs.kde.org/show_bug.cgi?id=285849#c6
I instrumented the call which causes the NULL pointer dereference. And sure enough, I finally triggered the crash. Here is my output:
Triggered histogram crash!
Dumping class state:
sixteenBits: 0
guideVisible: 0
statisticsVisible: 1
inSelected: 0
selectMode: 1
showProgress: 1
renderingType: 0
range: 255
state: 0
channelType: 0
scaleType: 1
imageHistogram: 0x0
selectionHistogram: 0x0
xmin: 0.000000
xminOrg: 0.000000
xmax: 0.000000
animationState: 0
animation: 0x36eb890
histogramPainter: 0x36ec610
arguments:
i_idata: 0x0, i_w: 0d, i_h: 0d
i_sixteenBits: 0
s_idata: 0x0, s_w: 0d, s_h: 0d
showProgress: 1
I will now apply the patch you posted and see whether it also fixes the problem. You can still use my dump output to verify whether your patch would address this state.
Rudolf, My patch in git/master fix the problem for you ? Gilles Caulier Your patch does the same as my instrumentation and I indeed had no crash anymore with this change. I did spend some effort looking a little bit deeper into the problem last night and think it has something to do with image crop selection returning bad values, which leads to an illegal clip rectangle. If the DImg::copy in imagepropertiescolorstab.cpp:541 is fed a bad rectangle, an empty image is returned which ultimately produces exactly the numbers my dump showed in Comment 21. And I strongly suspect that there is something rotten in the state of ImagePropertiesSideBar::slotImageSelectionChanged or rather the function triggering it, because for some reason I can never select the whole image, there is always something cropped off the right and bottom side. Press Ctrl+A and Ctrl+X often enough and the whole image disappears. I know, I know, this should be a separate bug report .... I will report my findings, for the time the patch is a quick fix for the obvious symptom. Thanks Rudolf for your investiguations... Gilles Caulier If selection is stored in integers and the picture is zoomed, there can and will be rounding errors, this may explain your latter observations. Did you experience any other adverse effect when bad values come from somewhere when the crop rectangle is moving? *** Bug 288823 has been marked as a duplicate of this bug. *** Created attachment 67700 [details]
New crash information added by DrKonqi
digikam (2.1.1) on KDE Platform 4.7.4 (4.7.4) using Qt 4.7.4
- What I was doing when the application crashed:
Trying to apply color changes, whe clicked on color button, it just crashed.
-- Backtrace (Reduced):
#7 Digikam::ImageHistogram::calculate (this=0xaa988d8) at /build/buildd/digikam-2.1.1/core/libs/dimg/filters/levels/imagehistogram.cpp:237
#8 0xb6928dcb in Digikam::ImageHistogram::run (this=0xaa988d8) at /build/buildd/digikam-2.1.1/core/libs/dimg/filters/levels/imagehistogram.cpp:174
#9 0xb6a5a8ee in Digikam::DynamicThread::DynamicThreadPriv::run (this=0xbb2b570) at /build/buildd/digikam-2.1.1/core/libs/threads/dynamicthread.cpp:328
#10 0xb4b83651 in QThreadPoolThread::run (this=0xb37dcf0) at concurrent/qthreadpool.cpp:106
#11 0xb4b8f7b3 in QThreadPrivate::start (arg=0xb37dcf0) at thread/qthread_unix.cpp:331
Luis, I applied patch to consolidate code with 2.4.1. release, not 2.1.1. Please update and try again. Note that me and Marcel, we never reproduce the crash. So it's difficult to hack... Gilles Caulier Official digiKam 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier A number of updates have been made to Ubuntu in the meantime which made this bug mysteriously disappear, with or without the patch. I have not been able to reproduce the problem ever since. I'd recommend this bug gets closed until new reports come in (unlikely IMHO). *** Bug 302678 has been marked as a duplicate of this bug. *** Created attachment 72987 [details]
New crash information added by DrKonqi
digikam (2.7.0) on KDE Platform 4.7.4 (4.7.4) using Qt 4.7.4
- What I was doing when the application crashed: I edited a .nef raw-picture using the solarizing kipi plugin
-- Backtrace (Reduced):
#7 Digikam::ImageHistogram::calculate (this=0x970fb20) at /build/buildd/digikam-2.7.0/core/libs/dimg/filters/levels/imagehistogram.cpp:218
#8 0x011a625b in Digikam::ImageHistogram::run (this=0x970fb20) at /build/buildd/digikam-2.7.0/core/libs/dimg/filters/levels/imagehistogram.cpp:174
#9 0x012da19e in Digikam::DynamicThread::DynamicThreadPriv::run (this=0xbb0fad8) at /build/buildd/digikam-2.7.0/core/libs/threads/dynamicthread.cpp:186
#10 0x01567651 in QThreadPoolThread::run (this=0xabf4cc0) at concurrent/qthreadpool.cpp:106
#11 0x015737b3 in QThreadPrivate::start (arg=0xabf4cc0) at thread/qthread_unix.cpp:331
*** Bug 304673 has been marked as a duplicate of this bug. *** *** Bug 301051 has been marked as a duplicate of this bug. *** Git commit 04933fa86122db4e1cc20df15ea9c6250cb6325f by Gilles Caulier. Committed on 01/10/2012 at 23:51. Pushed by cgilles into branch 'master'. use DImg image histogram constructor everywhere M +1 -2 libs/dimg/filters/auto/autolevelsfilter.cpp M +1 -2 libs/dimg/filters/auto/equalizefilter.cpp M +1 -2 libs/dimg/filters/auto/stretchfilter.cpp M +2 -1 libs/dimg/filters/curves/curveswidget.cpp M +3 -2 libs/dimg/filters/levels/histogramwidget.cpp M +0 -6 libs/dimg/filters/levels/imagehistogram.cpp M +0 -2 libs/dimg/filters/levels/imagehistogram.h M +3 -8 libs/dimg/filters/wb/wbfilter.cpp http://commits.kde.org/digikam/04933fa86122db4e1cc20df15ea9c6250cb6325f Git commit 1a0bbc83b837d9a272842accea777b66227f7f89 by Gilles Caulier. Committed on 02/10/2012 at 09:53. Pushed by cgilles into branch 'master'. store internal image data in DImg Container. M +27 -30 libs/dimg/filters/levels/imagehistogram.cpp M +1 -1 libs/dimg/filters/levels/imagehistogram.h http://commits.kde.org/digikam/1a0bbc83b837d9a272842accea777b66227f7f89 Git commit 445c84557a943a281856cdf2451d7e4ddc78b9bf by Gilles Caulier. Committed on 02/10/2012 at 12:59. Pushed by cgilles into branch 'master'. remove HistogramWidget constructor with image data argumets. Use updtaeData() methods to pass image data. Clenup and simplifcation of API M +5 -5 imageplugins/color/adjustlevelstool.cpp M +6 -5 imageplugins/color/filmtool.cpp M +0 -29 libs/dimg/filters/levels/histogramwidget.cpp M +1 -20 libs/dimg/filters/levels/histogramwidget.h http://commits.kde.org/digikam/445c84557a943a281856cdf2451d7e4ddc78b9bf Git commit ca4d5e3ed151ee0e0150732d0a046632b26449e6 by Gilles Caulier. Committed on 02/10/2012 at 13:47. Pushed by cgilles into branch 'master'. remove all methods to update image data based on ucher pointers. Used DImg container instead. API polish and simplification. M +1 -17 imageplugins/color/adjustcurvestool.cpp M +2 -21 imageplugins/color/adjustlevelstool.cpp M +1 -17 imageplugins/color/autocorrectiontool.cpp M +1 -17 imageplugins/color/bcgtool.cpp M +1 -17 imageplugins/color/bwsepiatool.cpp M +1 -17 imageplugins/color/cbtool.cpp M +1 -17 imageplugins/color/channelmixertool.cpp M +2 -17 imageplugins/color/filmtool.cpp M +1 -17 imageplugins/color/hsltool.cpp M +1 -17 imageplugins/color/profileconversiontool.cpp M +3 -18 imageplugins/color/whitebalancetool.cpp M +3 -18 imageplugins/enhance/localcontrasttool.cpp M +1 -20 imageplugins/enhance/redeyetool.cpp M +2 -11 imageplugins/filters/colorfxtool.cpp M +1 -3 imageplugins/transform/ratiocroptool.cpp M +10 -14 libs/dimg/filters/levels/histogramwidget.cpp M +4 -6 libs/dimg/filters/levels/histogramwidget.h M +16 -32 libs/imageproperties/imagepropertiescolorstab.cpp M +1 -1 utilities/imageeditor/rawimport/rawsettingsbox.cpp M +1 -2 utilities/setup/setupeditor.cpp http://commits.kde.org/digikam/ca4d5e3ed151ee0e0150732d0a046632b26449e6 Marcel, I have been able to reproduce the crash in ImageHistogram with 3.0.0 in certain conditions, when Color tab is visible from right sidebar tab... I ported all code relevant of histogram management to DImg and removed all methods and constructors using pointer to uchar data container. In all case this is more safe and clean. Code sound better. I'm sure that it's a race condition relevant of image data deleted during histogram computation. using DImg will prevent this. Also, i'm not able to reproduce the crash now, after few intensive race condition test in my fast computer. It still a point to clear before to close this file. Look here : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/filters/levels/imagehistogram.cpp#L90 Do i need really to make a deep copy of image here ? Because it will mangle more memory, and i'm not sure that it must necessary to prevent race condition of image data deleted. Typically the DImg shared data reference mechanism must be safe and enough. Right ? Gilles We are safe that the data will not be deleted (a reference is kept, and data is deleted only when the last reference is dropped) But we should be aware of a difference: DImg is explicitly shared, in contrast to implicitly shared classes like QString, QImage. That means a change to one copy of an image does not detach this copy, instead, the change will affect all shared instances. So, if e.g. the image editor gives the DImg to the sidebar, and then the data of the editor's main DImg is changed or resized, a shallow copy in the histogram will be immediately affected. This can lead to crashes, or can be safe, depending on the terms of use. Git commit 37a1414726f92a3ef3b350a7ff5a939c88d27307 by Gilles Caulier. Committed on 03/10/2012 at 10:05. Pushed by cgilles into branch 'master'. make a simple copy of reference instead a deep copy. This must be enough and optimum for memory allocation. FIXED-IN: 3.0.0 M +4 -1 libs/dimg/filters/levels/imagehistogram.cpp http://commits.kde.org/digikam/37a1414726f92a3ef3b350a7ff5a939c88d27307 Git commit 50939b7dd0c6a02761792c6f7750adcb8f30d9d0 by Gilles Caulier. Committed on 07/10/2012 at 07:23. Pushed by cgilles into branch 'master'. use DImg constructor instead pointer based image data arguments M +22 -20 libs/dimg/filters/bw/bwsepiasettings.cpp M +4 -4 libs/dimg/filters/bw/bwsepiasettings.h M +4 -4 libs/dimg/filters/curves/curvesbox.cpp M +2 -2 libs/dimg/filters/curves/curvesbox.h M +2 -2 libs/dimg/filters/curves/curvessettings.cpp M +3 -3 libs/dimg/filters/curves/curveswidget.cpp M +3 -5 libs/dimg/filters/curves/curveswidget.h M +1 -1 utilities/imageeditor/rawimport/rawimport.cpp M +1 -1 utilities/imageeditor/rawimport/rawsettingsbox.cpp http://commits.kde.org/digikam/50939b7dd0c6a02761792c6f7750adcb8f30d9d0 *** Bug 312048 has been marked as a duplicate of this bug. *** *** Bug 314833 has been marked as a duplicate of this bug. *** |