Bug 235491 - Regression in rev. 1115803, SIGSEGV or SIGABRT in image filters in editor.
Summary: Regression in rev. 1115803, SIGSEGV or SIGABRT in image filters in editor.
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Editor-Levels (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-26 22:47 UTC by Mikkel Christensen
Modified: 2017-08-09 15:12 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 1.3.0
Sentry Crash Report:


Attachments
Stack trace examples (20.18 KB, text/plain)
2010-04-26 22:49 UTC, Mikkel Christensen
Details
Another set of stack traces from revision 1118747 (7.68 KB, text/plain)
2010-04-27 23:58 UTC, Mikkel Christensen
Details
Another stack trace from HEAD (1119860) (3.04 KB, text/plain)
2010-04-28 00:32 UTC, Mikkel Christensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikkel Christensen 2010-04-26 22:47:50 UTC
Version:           SVN revision 1115803 (using Devel)
Compiler:          gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 
OS:                Linux
Installed from:    Compiled sources

In many image filters in the image editor, I now get crashes every time I open them.

I have isolated the bug to between revision 1115803 and 1115800.
The comment for this commit was "Port threaded filters to be a DynamicThread.
Mostly simple find-and-replace work." by mwieswig.

1115803 crashes consistently, 1115800 works without problems. I think there is a problem with some object being deleted too early. I have observed "d" pointers becoming zero, but also other behavior.

I will attach a file with stack trace samples.

This is a blocking bug for me that stops me from using digikam SVN later than 1115803.
Comment 1 Mikkel Christensen 2010-04-26 22:49:25 UTC
Created attachment 43052 [details]
Stack trace examples

Stack trace examples of crashes. See notes in file.
Comment 2 Marcel Wiesweg 2010-04-27 18:19:39 UTC
Please test at least revision 1118747. There was a relevant bug fixed. Please report further problems.
Comment 3 Mikkel Christensen 2010-04-27 23:58:59 UTC
Created attachment 43069 [details]
Another set of stack traces from revision 1118747

I finally managed to get revision 1118747 to run after working around the database bug! The problem is still there. Stack traces attached.
Don't ask me to try againg with HEAD (1119860 at the moment). I already did, and I can't build it (something about i18n arguments in a template).
Right now digikam SVN is so unstable that I can't get down to actually coding anything. I spend what little time I have on just making it build and run.

Best regards,
Mikkel
Comment 4 Mikkel Christensen 2010-04-28 00:32:20 UTC
Created attachment 43072 [details]
Another stack trace from HEAD (1119860)

I think I fixed the bug in HEAD and was able to test this bug again.

In the code below, d is NULL after the setPreviewImage call. d is ok before the call. 

void AdjustLevelsTool::putPreviewData()
{
    DImg preview = filter()->getTargetImage();
    d->previewWidget->setPreviewImage(preview);

    // Update histogram.

    if (d &&(d->destinationPreviewData))
       delete [] d->destinationPreviewData;

    d->destinationPreviewData = preview.copyBits();
    d->gboxSettings->histogramBox()->histogram()->updateData(d->destinationPreviewData,
                                                             preview.width(), preview.height(), preview.sixteenBit(),
                                                             0, 0, 0, false);
}
Comment 5 Mikkel Christensen 2010-04-28 09:54:28 UTC
Sorry, I think my previous comment might have been unclear. This image editor bug is still present in HEAD. (the one I said I fixed was the one preventing me from building).

Best regards,
Mikkel
Comment 6 Marcel Wiesweg 2010-04-29 22:08:39 UTC
I dont get these crashes here, valgrind check is also clean.

Note that most of your crashes occur in the filter constructors, when no thread has been run yet. Have you double checked no old binaries are lying around and are loaded? A binary compatibility problem would very well fit your problem.
Comment 7 Mikkel Christensen 2010-04-30 09:42:20 UTC
It appears there is something I don't understand about setting up my development environment. After making a full "make install" of digikam, the problem disappeared. When debugging in Eclipse, the problem was there. I thought I had set everything up right with environment variables etc. Apparently not.

Sorry to make all this trouble for nothing. Setting bug to FIXED,INVALID.

Best regards,
Mikkel