Summary: | Random crash when opening image in editor | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Heiner Lamprecht <heiner> |
Component: | DImg-Core | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 6.2.0 |
Description
Heiner Lamprecht
2006-08-19 18:36:48 UTC
Yes, i can reproduce this crash on some computer but not everywhere. I suspect a problem in common plugin dialog implementation. Gilles I changed the type of the variable "size" in "int DImg::allocateData()" from int to ullong, and it seems to help a lot: ullong size = m_priv->width * m_priv->height * (m_priv->sixteenBit ? 8 : 4); instead of: int size = m_priv->width * m_priv->height * (m_priv->sixteenBit ? 8 : 4); I'm not 100% sure, because the crash only occured randomly. But while stressing digikam, nothing happend. The only crashes still remaining are related to debugging information. They occur in lines, where kdDebug() is called. I'll keep on investigating on this. Heiner This crash is strange, because it only appear with only one image plugins dialog type (here the common dialog used by Refocus, Noise Reduction, Unsharp Mask, etc.) To have recently works many time with Add Border plugin witch use another common dialog type, no crash appear. Both dialog type use a separate thread to compute image manipulation algorithms. I don't understand why your fix help a lot. The allocateData() method is used in both dialog (via the DImg class in fact). Marcel, can you reproduce this crash in your computer ? Gilles Note: I suspect than the crash is relevant of gui event. This is why it can be difficult to reproduce it. Gilles On Thursday 24 August 2006 12:07, Gilles Caulier wrote:
>
> ------- Additional Comments From caulier.gilles free fr
> 2006-08-24 12:07 ------- Note: I suspect than the crash is
> relevant of gui event. This is why it can be difficult to
> reproduce it.
Well, it is difficult ;-(
I removed most debugging lines (kdDebug() ...), which made the
program somehow more stable. But it still crashes a lot. Working
is nearly impossible at the moment. I invested a lot in a new
computer, and now this ;-(
Does anybody have any idea what to do or where to look at? Are
there any other users here, who have a x86_64 system?
My system:
uname -a
Linux tharbad 2.6.16.21-0.13-smp #1 SMP Mon Jul 17 17:22:44 UTC 2006
x86_64 x86_64 x86_64 GNU/Linux
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
cpu MHz : 2800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
syscall lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 6030.80
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
cpu MHz : 2800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
syscall lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 6021.74
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
Am Donnerstag, 24. August 2006 12:06 schrieb Gilles Caulier: [bugs.kde.org quoted mail] I had this crash from time to time since the 0.8 version. As far as I can remember it occured in refocus plugin only. The sensitivity never changed. Gerhard -- www.gerhard.fr I have not been able to reproduce this here so far. If anyone can reliably reproduce it, some debug statements in DImg::allocateData might help. But from the backtrace, width is 515 and height 805 which is all right. Marcel, i can reproduce the crash, and it's relevant of HyperThreading option enable in your computer (if you have)... In fact, this bug is a dupplicate of #133026. Look my last comments in this file. Gilles *** This bug has been marked as a duplicate of 133026 *** Fixed with bug #133026 |