[Bug 273765] New: replacing pgf files with an open digikam lead to reproducible crash

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] New: replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765

           Summary: replacing pgf files with an open digikam lead to
                    reproducible crash
           Product: digikam
           Version: 2.0.0
          Platform: Compiled Sources
        OS/Version: Linux
            Status: NEW
          Severity: crash
          Priority: NOR
         Component: general
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:           2.0.0 (using KDE 4.6.3)
OS:                Linux

ok, I'm a bit stuck in debugging this one, while it's a corner case it would be
interesting to discover why the crash happen.

The point I'm stuck at is how to correlate the backtrace of the signalled
thread, working in pgf library to a call in digikam

there is some way to know from where the data is feed into libpgf?

BTW the crash happen even with external libpgf

Reproducible: Always

Steps to Reproduce:
1) download a bunch of .nef files in raw/
2) convert it to lossy pgf (resized) to be put in tmp/
3) change your mind, w/o close digikam open a shell and remove all files in
tmp/
4) convert raw/ and put it again in tmp/ this time with lossless pgf
compression
5) close and reopen digikam, then try to navigate into tmp/
6) crash




tried to use gdb for the live program but found that working on a core file has
more flexibility so:

digikam.sh --nocrashhandler
# steps to reproduce
gdb /home/vivo/usr/bin/digikam  core

(gdb) info threads
  7 Thread 18247  0x00007fdf6625b54e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
  6 Thread 16802  0x00007fdf652927e9 in ?? () from /lib64/libc.so.6
  5 Thread 18245  0x00007fdf6625b54e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
  4 Thread 16807  0x00007fdf6625b1e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
  3 Thread 16808  0x00007fdf6527db23 in poll () from /lib64/libc.so.6
  2 Thread 16895  0x00007fdf6625b1e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
* 1 Thread 18246  ClearBitBlock (stream=0x7fdf26ba94c0, pos=82071, len=<value
optimized out>)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/BitStream.h:159

(gdb) info source
Current source file is
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/BitStream.h
Compilation directory is
/home/vivo/digikam-devel/digikam-sc/build2/core/digikam
Located in /srv/git/digikam-sc/core/libs/3rdparty/libpgf/BitStream.h
Contains 269 lines.
Source language is c++.
Compiled with unknown debugging format.
Includes preprocessor macro info.

(gdb) info line
Line 159 of
"/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/BitStream.h"
   starts at address 0x7fdf6b2ab8e0 <ClearBitBlock(UINT32*, UINT32, UINT32)+48>
and ends at 0x7fdf6b2ab8e3 <ClearBitBlock(UINT32*, UINT32, UINT32)+51>.
(gdb)

(gdb) frame 1
#1  0x00007fdf6b2aaaab in CDecoder::RLDSigsAndSigns (this=0x7fdf44095d90,
bufferSize=16384, codeLen=109243, sigBits=0x7fdf26ba94c0,
signBits=0x7fdf26ba8cc0)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp:726
726                             ClearBitBlock(sigBits, sigPos, runlen);
(gdb) line
Undefined command: "line".  Try "help".
(gdb) info line
Line 726 of
"/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp"
   starts at address 0x7fdf6b2aaa93 <CDecoder::RLDSigsAndSigns(UINT32, UINT32,
UINT32*, UINT32*)+291>
   and ends at 0x7fdf6b2aaa96 <CDecoder::RLDSigsAndSigns(UINT32, UINT32,
UINT32*, UINT32*)+294>.

(gdb) frame 2
#2  0x00007fdf6b2aaea0 in CDecoder::BitplaneDecode (this=0x7fdf44095d90,
bufferSize=16384)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp:536
536                             sigLen = RLDSigsAndSigns(bufferSize, codeLen,
sigBits, signBits); ASSERT(sigLen <= bufferSize);
(gdb) info line
Line 536 of
"/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp"
   starts at address 0x7fdf6b2aad46 <CDecoder::BitplaneDecode(UINT32)+278> and
ends at 0x7fdf6b2aad4e <CDecoder::BitplaneDecode(UINT32)+286>.


(gdb) thread apply all bt

Thread 7 (Thread 18247):
#0  0x00007fdf6625b54e in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007fdf664ec1b8 in wait (this=<value optimized out>, mutex=0x18fc5a0,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x18fc5a0,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x00007fdf664df19f in QThreadPoolThread::run (this=0x54496b0) at
concurrent/qthreadpool.cpp:140
#4  0x00007fdf664eba8a in QThreadPrivate::start (arg=0x54496b0) at
thread/qthread_unix.cpp:320
#5  0x00007fdf66256c00 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fdf65285b0d in clone () from /lib64/libc.so.6


Thread 6 (Thread 16802):
#0  0x00007fdf652927e9 in ?? () from /lib64/libc.so.6
#1  0x00007fdf65229ea6 in ?? () from /lib64/libc.so.6
#2  0x00007fdf65227eca in malloc () from /lib64/libc.so.6
#3  0x00007fdf65a8f1ad in operator new(unsigned long) () from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6
#4  0x00007fdf67395ddc in QPainter::save (this=<value optimized out>) at
painting/qpainter.cpp:1604
#5  0x00007fdf4e5973b3 in Oxygen::Style::drawControl (this=0x172e0b0,
element=QStyle::CE_ShapedFrame, option=0x7ffffa529200, painter=0x7ffffa529290,
widget=
    0x17f5170) at
/usr/src/debug/kde-base/kstyles-4.6.3/kstyles-4.6.3/kstyles/oxygen/oxygenstyle.cpp:1026
#6  0x00007fdf676702ed in QFrame::drawFrame (this=0x17f5170, p=0x7ffffa529290)
at widgets/qframe.cpp:534
#7  0x00007fdf676703a8 in QFrame::paintEvent (this=0x17f5170) at
widgets/qframe.cpp:496
#8  0x00007fdf67292590 in QWidget::event (this=0x17f5170, event=0x7ffffa529b00)
at kernel/qwidget.cpp:8405
#9  0x00007fdf67670446 in QFrame::event (this=0x17f5170, e=0x7ffffa529b00) at
widgets/qframe.cpp:557
#10 0x00007fdf67238ea4 in QApplicationPrivate::notify_helper (this=0x16fbc80,
receiver=0x17f5170, e=0x7ffffa529b00) at kernel/qapplication.cpp:4462
#11 0x00007fdf6723e351 in QApplication::notify (this=<value optimized out>,
receiver=0x17f5170, e=0x7ffffa529b00) at kernel/qapplication.cpp:4341
#12 0x00007fdf67ff4002 in KApplication::notify (this=0x7ffffa52b5b0,
receiver=0x17f5170, event=0x7ffffa529b00)
    at
/usr/src/debug/kde-base/kdelibs-4.6.3-r1/kdelibs-4.6.3/kdeui/kernel/kapplication.cpp:311
#13 0x00007fdf665e4a9b in QCoreApplication::notifyInternal
(this=0x7ffffa52b5b0, receiver=0x17f5170, event=0x7ffffa529b00) at
kernel/qcoreapplication.cpp:731
#14 0x00007fdf6728f17e in sendSpontaneousEvent (this=0x18e3ae0, pdev=0x18e3998,
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x19347e0)
    at ../../src/corelib/kernel/qcoreapplication.h:218
#15 QWidgetPrivate::drawWidget (this=0x18e3ae0, pdev=0x18e3998, rgn=...,
offset=..., flags=4, sharedPainter=0x0, backingStore=0x19347e0)
    at kernel/qwidget.cpp:5492
#16 0x00007fdf6728fddd in QWidgetPrivate::paintSiblingsRecursive
(this=0x18dfed0, pdev=0x18e3998, siblings=..., index=<value optimized out>,
rgn=...,
    offset=..., flags=4, sharedPainter=0x0, backingStore=0x19347e0) at
kernel/qwidget.cpp:5699
#17 0x00007fdf6728fc93 in QWidgetPrivate::paintSiblingsRecursive
(this=0x18dfed0, pdev=0x18e3998, siblings=..., index=132, rgn=..., offset=...,
flags=4,
    sharedPainter=0x0, backingStore=0x19347e0) at kernel/qwidget.cpp:5686
#18 0x00007fdf6728fc93 in QWidgetPrivate::paintSiblingsRecursive
(this=0x18dfed0, pdev=0x18e3998, siblings=..., index=151, rgn=..., offset=...,
flags=4,
    sharedPainter=0x0, backingStore=0x19347e0) at kernel/qwidget.cpp:5686
#19 0x00007fdf6728ee40 in QWidgetPrivate::drawWidget (this=0x18dfed0,
pdev=0x18e3998, rgn=..., offset=..., flags=<value optimized out>,
sharedPainter=0x0,
    backingStore=0x19347e0) at kernel/qwidget.cpp:5545
#20 0x00007fdf6747fdd5 in QWidgetBackingStore::sync (this=0x19347e0) at
painting/qbackingstore.cpp:1333
#21 0x00007fdf67283bd0 in QWidgetPrivate::syncBackingStore (this=0x18dfed0) at
kernel/qwidget.cpp:1842
#22 0x00007fdf67292d02 in QWidget::event (this=0x1879de0, event=0x7fdf4400bc80)
at kernel/qwidget.cpp:8552
#23 0x00007fdf6768badb in QMainWindow::event (this=0x1879de0,
event=0x7fdf4400bc80) at widgets/qmainwindow.cpp:1480
#24 0x00007fdf680e6990 in KXmlGuiWindow::event (this=0x1879de0,
ev=0x7fdf4400bc80)
    at
/usr/src/debug/kde-base/kdelibs-4.6.3-r1/kdelibs-4.6.3/kdeui/xmlgui/kxmlguiwindow.cpp:126
#25 0x00007fdf67238ea4 in QApplicationPrivate::notify_helper (this=0x16fbc80,
receiver=0x1879de0, e=0x7fdf4400bc80) at kernel/qapplication.cpp:4462
#26 0x00007fdf6723e351 in QApplication::notify (this=<value optimized out>,
receiver=0x1879de0, e=0x7fdf4400bc80) at kernel/qapplication.cpp:4341
#27 0x00007fdf67ff4002 in KApplication::notify (this=0x7ffffa52b5b0,
receiver=0x1879de0, event=0x7fdf4400bc80)
    at
/usr/src/debug/kde-base/kdelibs-4.6.3-r1/kdelibs-4.6.3/kdeui/kernel/kapplication.cpp:311
#28 0x00007fdf665e4a9b in QCoreApplication::notifyInternal
(this=0x7ffffa52b5b0, receiver=0x1879de0, event=0x7fdf4400bc80) at
kernel/qcoreapplication.cpp:731
#29 0x00007fdf665e89be in sendEvent (receiver=0x0, event_type=0,
data=0x16b2a00) at kernel/qcoreapplication.h:215
#30 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0,
data=0x16b2a00) at kernel/qcoreapplication.cpp:1372
#31 0x00007fdf66612c53 in sendPostedEvents (s=<value optimized out>) at
kernel/qcoreapplication.h:220
#32 postEventSourceDispatch (s=<value optimized out>) at
kernel/qeventdispatcher_glib.cpp:277
#33 0x00007fdf64acdb3e in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#34 0x00007fdf64ace328 in ?? () from /usr/lib64/libglib-2.0.so.0
#35 0x00007fdf64ace5bd in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#36 0x00007fdf66612def in QEventDispatcherGlib::processEvents (this=0x16faff0,
flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:422
#37 0x00007fdf672ea03e in QGuiEventDispatcherGlib::processEvents (this=<value
optimized out>, flags=<value optimized out>)
    at kernel/qguieventdispatcher_glib.cpp:204
#38 0x00007fdf665e3562 in QEventLoop::processEvents (this=<value optimized
out>, flags=...) at kernel/qeventloop.cpp:149
#39 0x00007fdf665e37a5 in QEventLoop::exec (this=0x7ffffa52b3f0, flags=...) at
kernel/qeventloop.cpp:201
#40 0x00007fdf665e8cb9 in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1008
#41 0x000000000063635f in main (argc=7818496, argv=0x7ffffa52bc58) at
/home/vivo/digikam-devel/digikam-sc/core/digikam/main/main.cpp:232

Thread 5 (Thread 18245):
#0  0x00007fdf6625b54e in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007fdf664ec1b8 in wait (this=<value optimized out>, mutex=0x18fc5a0,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x18fc5a0,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x00007fdf664df19f in QThreadPoolThread::run (this=0x5f1c430) at
concurrent/qthreadpool.cpp:140
#4  0x00007fdf664eba8a in QThreadPrivate::start (arg=0x5f1c430) at
thread/qthread_unix.cpp:320
#5  0x00007fdf66256c00 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fdf65285b0d in clone () from /lib64/libc.so.6

Thread 4 (Thread 16807):
#0  0x00007fdf6625b1e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007fdf664ec29f in wait (this=<value optimized out>, mutex=0x17fc0d8,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x17fc0d8,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x000000000058b2a1 in Digikam::ScanController::run (this=0x17fbd60) at
/home/vivo/digikam-devel/digikam-sc/core/digikam/database/scancontroller.cpp:618
#4  0x00007fdf664eba8a in QThreadPrivate::start (arg=0x17fbd60) at
thread/qthread_unix.cpp:320
#5  0x00007fdf66256c00 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fdf65285b0d in clone () from /lib64/libc.so.6

Thread 3 (Thread 16808):
#0  0x00007fdf6527db23 in poll () from /lib64/libc.so.6
#1  0x00007fdf64ace08d in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fdf64ace5bd in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#3  0x00007fdf66612def in QEventDispatcherGlib::processEvents (this=0x182d6d0,
flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:422
#4  0x00007fdf665e3562 in QEventLoop::processEvents (this=<value optimized
out>, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007fdf665e37a5 in QEventLoop::exec (this=0x7fdf49672d20, flags=...) at
kernel/qeventloop.cpp:201
#6  0x00007fdf664e8db8 in QThread::exec (this=<value optimized out>) at
thread/qthread.cpp:492
#7  0x00007fdf665c3480 in QInotifyFileSystemWatcherEngine::run (this=0x183a020)
at io/qfilesystemwatcher_inotify.cpp:248
#8  0x00007fdf664eba8a in QThreadPrivate::start (arg=0x183a020) at
thread/qthread_unix.cpp:320
#9  0x00007fdf66256c00 in start_thread () from /lib64/libpthread.so.0
#10 0x00007fdf65285b0d in clone () from /lib64/libc.so.6

Thread 2 (Thread 16895):
#0  0x00007fdf6625b1e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007fdf664ec29f in wait (this=<value optimized out>, mutex=0x18cf348,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x18cf348,
time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x00007fdf6b2b89c6 in Digikam::ParkingThread::run (this=0x18cf330) at
/home/vivo/digikam-devel/digikam-sc/core/libs/threads/threadmanager.cpp:119
#4  0x00007fdf664eba8a in QThreadPrivate::start (arg=0x18cf330) at
thread/qthread_unix.cpp:320
#5  0x00007fdf66256c00 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fdf65285b0d in clone () from /lib64/libc.so.6

Thread 1 (Thread 18246):
#0  ClearBitBlock (stream=0x7fdf26ba94c0, pos=82071, len=<value optimized out>)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/BitStream.h:159
#1  0x00007fdf6b2aaaab in CDecoder::RLDSigsAndSigns (this=0x7fdf44095d90,
bufferSize=16384, codeLen=109243, sigBits=0x7fdf26ba94c0,
signBits=0x7fdf26ba8cc0)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp:726
#2  0x00007fdf6b2aaea0 in CDecoder::BitplaneDecode (this=0x7fdf44095d90,
bufferSize=16384)
    at
/home/vivo/digikam-devel/digikam-sc/core/libs/3rdparty/libpgf/Decoder.cpp:536
#3  0x0000000000000000 in ?? ()

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Gilles Caulier-4
https://bugs.kde.org/show_bug.cgi?id=273765


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|general                     |Database




--- Comment #1 from Gilles Caulier <caulier gilles gmail com>  2011-05-21 11:11:22 ---

>there is some way to know from where the data is feed into libpgf?

I/O PGF image data are wrapped to QImage in this source code :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/pgfutils.cpp

And managed in DB with this class :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailcreator.cpp#L886

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailcreator.cpp#L886

>BTW the crash happen even with external libpgf


Are you sure, because in your backtrace, you use libpgf from 3rdparty digiKam
core...

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #2 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-05-21 12:40:27 ---
Are steps 1) to 3) really necessary to reproduce? Could it be there is "simply"
a PGF file produced by digikam which crashes digikam when opened?

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #3 from Francesco Riosa <francesco+kde pnpitalia it>  2011-05-23 16:21:05 ---
Created an attachment (id=60243)
 --> (http://bugs.kde.org/attachment.cgi?id=60243)
getThumbs.py extract pgf thumbnail from database

(In reply to comment #1)
[snip]
> >BTW the crash happen even with external libpgf
>
> Are you sure, because in your backtrace, you use libpgf from 3rdparty digiKam
> core...

yes, I've recompiled digiKam with internal libpgf only later and the backtrace
is the same
I'm digging the sources right now at least to understund how it crashes, thanks
for the pointers

(In reply to comment #2)
> Are steps 1) to 3) really necessary to reproduce? Could it be there is "simply"
> a PGF file produced by digikam which crashes digikam when opened?

No, that's how the problem generated initially, there is _only_ a pgf broken:
http://xn--wtf-xs0a.ws/Bug273765/_dsc4243.pgf

I've also extracted all thumbnails from the database to pgf files and they are
all readable

I'm looking into showfoto, since it's reproducible there and there are less
threads involved ;)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

S. Burmeister
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765


S. Burmeister <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #4 from S. Burmeister <sven burmeister gmx net>  2011-05-23 22:43:49 ---
Self-compiled without external libpgf crashes when I press F4 to edit the
image. Preview etc. works ok.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa2b2ab70 (LWP 32539)]
0xb672036b in ClearBitBlock (stream=0xa2b28724, pos=73170, len=16384)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/BitStream.h:159
159                             stream[i] = 0;
(gdb) bt
#0  0xb672036b in ClearBitBlock (stream=0xa2b28724, pos=73170, len=16384)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/BitStream.h:159
#1  0xb671ff7b in CDecoder::RLDSigsAndSigns (this=0xa1ac3738, bufferSize=16384,
codeLen=522, sigBits=0xa2b28724, signBits=0xa2b27f24)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/Decoder.cpp:726
#2  0xb671f9e6 in CDecoder::BitplaneDecode (this=0x0, bufferSize=0)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/Decoder.cpp:536
#3  0x00000000 in ?? ()
(gdb) 292056 FLAGS ($IGNORED)

#0  0xb672036b in ClearBitBlock (stream=0xa2b28724, pos=73170, len=16384)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/BitStream.h:159
#1  0xb671ff7b in CDecoder::RLDSigsAndSigns (this=0xa1ac3738, bufferSize=16384,
codeLen=522, sigBits=0xa2b28724, signBits=0xa2b27f24)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/Decoder.cpp:726
#2  0xb671f9e6 in CDecoder::BitplaneDecode (this=0x0, bufferSize=0)
    at
/home/rabauke/devel/src/digikam-software-compilation/core/libs/3rdparty/libpgf/Decoder.cpp:536
#3  0x00000000 in ?? ()


konsole output:

QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in
use, all queries will cease to work.
digikam(32499)/KIPI (loading) KIPI::PluginLoader::Info::plugin:
KIPI::PluginLoader:: createInstance returned 0 for  "Kalender"  (
"kipiplugin_calendar" )  with error:  "Could not find plugin 'Kalender' for
application 'digikam'"
digikam(32499)/KIPI (loading) KIPI::PluginLoader::Info::plugin:
KIPI::PluginLoader:: createInstance returned 0 for  "DNGkonverter"  (
"kipiplugin_dngconverter" )  with error:  "Could not find plugin 'DNGkonverter'
for application 'digikam'"
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Exiv2::PgfImage::readMetadata: Reading PGF file
/home/rabauke/Pictures/_dsc4243.pgf
Exiv2::PgfImage: PGF header size : 79242 bytes
Exiv2::PgfImage::readMetadata: Found Image data (79226 bytes)
Speicherzugriffsfehler

(memory corruption)

digiKam version 2.0.0-beta6
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibClapack: internal library
LibExiv2: 0.20
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.6.3 (4.6.3)
LibKExiv2: 2.0.0
LibKMap: 2.0.0
LibKdcraw: 2.0.0
LibLCMS: 119
LibPGF: 6.09.44 - internal library
LibPNG: 1.4.4
LibQt: 4.7.3
LibRaw: 0.13.5
LibTIFF: LIBTIFF, Version 3.9.4 Copyright (c) 1988-1996 Sam Leffler Copyright
(c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.11.2 (Stable Release)
Parallelized demosaicing: Yes
Database backend: QSQLITE
LibGphoto2: 2.4.10
LibKface: 2.0.0
LibKipi: 1.2.0
LibOpenCV: 2.2.0
Libface: 0.2

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #5 from Francesco Riosa <francesco+kde pnpitalia it>  2011-05-24 21:22:48 ---
ok, after a lot of learning of gdb, and some reading on signals and exceptions
and also pgf specs:

There are two parts of this bug:
The first is a bad pgf file generated from the batch queque manager, I would
consider this a non issue, since there was intervention from the shell while
digikam was still running

The second is a unpleasant crash when a corrupted file is loaded:

The file is corrupted (redoing it give a correct one #1), _dsc4243.pgf headers
are correct #2 so it pass all initial checks and then if asserts are enabled it
trigger
ASSERT(sigPos + runlen <= BufferSize);
in Decoder.cpp:725 CDecoder::RLDSigsAndSigns(...)

For this example it's impossible to catch the problem early as it's done for
other things in pgfloader.cpp

Seem to me that the only solutions available are:
- rewrite libpgf to handle exceptions (slowing it down) and to fit better in a
qt env (no no no)
- fork an external process to read te image (like plasma does with plasmoids)
which can be inefficient at best
- register a SIGINT catcher
- close as wont fix

any ideas?

Note to self: converting .nef in batch resize+pgf does not give byte exact
files if run twice there are usually at least 3 or 4 bytes that differ

#1 http://xn--wtf-xs0a.ws/Bug273765/_dsc4243_ok.pgf
#2 I've created a structure for okteta available here:
http://kde-files.org/content/show.php/PGF+file+header+definition?content=142016

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #6 from Francesco Riosa <francesco+kde pnpitalia it>  2011-05-24 21:27:28 ---
(In reply to comment #5)
> - rewrite libpgf to handle exceptions (slowing it down) and to fit better in a

PGFplatform.h already contain the code below:

#ifndef ASSERT
    #ifdef _DEBUG
        #define ASSERT(x)    assert(x)
    #else
        #if defined(__GNUC__)
            #define ASSERT(ignore)((void) 0)
        #elif _MSC_VER >= 1300
            #define ASSERT        __noop
        #else
            #define ASSERT ((void)0)
        #endif
    #endif //_DEBUG
#endif //ASSERT

Maybe something easy can be added here and the Decoder.ccp line //ASSERT(sigPos
+ runlen <= BufferSize); uncommented

now something what?

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Gilles Caulier-4
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rschweizer@schweizer-inform
                   |                            |atik.ch




--- Comment #7 from Gilles Caulier <caulier gilles gmail com>  2011-05-26 19:54:16 ---
Francesco,

I CC Raphael Schweizer, who is LibPGF author and maintainer. We will see if he
can help us to hack this indeep problem in PGF library.

PS: Can you check if valgrind give more info about libpgf problem ?

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #8 from Francesco Riosa <francesco+kde pnpitalia it>  2011-05-29 15:11:15 ---
Created an attachment (id=60435)
 --> (http://bugs.kde.org/attachment.cgi?id=60435)
valgrind-broken-pgf.zip

valgrind-broken-pgf.zip include the output from:

valgrind --tool=memcheck --leak-check=full \
  --error-limit=no --suppressions=project/digikam.supp \
  showfoto --nocrashhandler _dsc4243_ok.pgf \
  > valgrind-pgf-ok-1.txt \
  2> valgrind-pgf-ok-2.txt

and similar for the broken pdf

lines 273-335 of valgrind-pgf-bad-2.txt show the program starting to crash
there is a "Invalid write of size 4" followed by "Invalid read of size 4"

"Conditional jump or move depends on uninitialised value" it's an error that in
the opening of a "good" pgf file happen only once, opening the bad pgf it's
ubiquitus

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #9 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-05-29 17:15:48 ---
libpgf should not crash, but crashes happen (unexpected by the programmer) and
are fixed when seen.

But it must never never never abort because of an error that it has seen and
has checked for (expected by the programmer).
It must fail loading the invalid file, but not crash the whole process!!

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Raphael Schweizer
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #10 from Raphael Schweizer <rschweizer schweizer-informatik ch>  2011-05-30 13:06:27 ---
Francesco,

thanks for reporting this issue and gathering all the helpful details.
We will investigate further and provide a patch shortly.

Raphael

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #11 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-05-30 21:45:40 ---
Thanks Raphael. I may also once again bring this image to your attention:
http://digikam3rdparty.free.fr/TEST_IMAGES/PGF/DSC03274_v1.pgf
which is also created by digikam and crashes at the same place

Valgrind:

==14132== Conditional jump or move depends on uninitialised value(s)
==14132==    at 0x7FBC016: CDecoder::ComposeBitplane(unsigned int, unsigned
int, unsigned int*, unsigned int*, unsigned int*) (BitStream.h:210)
==14132==    by 0x7FBC86B: CDecoder::BitplaneDecode(unsigned int)
(Decoder.cpp:603)
==14132==    by 0x7FBCAA9: CDecoder::DecodeBuffer() (Decoder.cpp:451)
==14132==    by 0x7FBCB41: CDecoder::DequantizeValue(CSubband*, unsigned int,
int) (Decoder.cpp:394)
==14132==    by 0x7FBD036: CDecoder::Partition(CSubband*, int, int, int, int,
int) (Decoder.cpp:213)
==14132==    by 0x7FC4D75: CSubband::PlaceTile(CDecoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:227)
==14132==    by 0x7FBF69D: CPGFImage::Read(int, bool (*)(double, bool, void*),
void*) (PGFimage.cpp:286)

==14132==
==14132== Conditional jump or move depends on uninitialised value(s)
==14132==    at 0x7FBC71A: CDecoder::BitplaneDecode(unsigned int)
(Decoder.cpp:526)
==14132==    by 0x7FBCAA9: CDecoder::DecodeBuffer() (Decoder.cpp:451)
==14132==    by 0x7FBCB41: CDecoder::DequantizeValue(CSubband*, unsigned int,
int) (Decoder.cpp:394)
==14132==    by 0x7FBD036: CDecoder::Partition(CSubband*, int, int, int, int,
int) (Decoder.cpp:213)
==14132==    by 0x7FC4D75: CSubband::PlaceTile(CDecoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:227)
==14132==    by 0x7FBF69D: CPGFImage::Read(int, bool (*)(double, bool, void*),
void*) (PGFimage.cpp:286)
==14132==    by 0x7E079B3: Digikam::PGFLoader::load(QString const&,
Digikam::DImgLoaderObserver*) (pgfloader.cpp:290)

==14132==
==14132== Conditional jump or move depends on uninitialised value(s)
==14132==    at 0x7FBC162: CDecoder::RLDSigsAndSigns(unsigned int, unsigned
int, unsigned int*, unsigned int*) (Decoder.cpp:690)
==14132==    by 0x7FBC911: CDecoder::BitplaneDecode(unsigned int)
(Decoder.cpp:536)
==14132==    by 0x7FBCAA9: CDecoder::DecodeBuffer() (Decoder.cpp:451)
==14132==    by 0x7FBCB41: CDecoder::DequantizeValue(CSubband*, unsigned int,
int) (Decoder.cpp:394)
==14132==    by 0x7FBD036: CDecoder::Partition(CSubband*, int, int, int, int,
int) (Decoder.cpp:213)
==14132==    by 0x7FC4D75: CSubband::PlaceTile(CDecoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:227)
==14132==    by 0x7FBF69D: CPGFImage::Read(int, bool (*)(double, bool, void*),
void*) (PGFimage.cpp:286)

==14132==
==14132== Conditional jump or move depends on uninitialised value(s)
==14132==    at 0x7FBC183: CDecoder::RLDSigsAndSigns(unsigned int, unsigned
int, unsigned int*, unsigned int*) (Decoder.cpp:691)
==14132==    by 0x7FBC911: CDecoder::BitplaneDecode(unsigned int)
(Decoder.cpp:536)
==14132==    by 0x7FBCAA9: CDecoder::DecodeBuffer() (Decoder.cpp:451)
==14132==    by 0x7FBCB41: CDecoder::DequantizeValue(CSubband*, unsigned int,
int) (Decoder.cpp:394)
==14132==    by 0x7FBD036: CDecoder::Partition(CSubband*, int, int, int, int,
int) (Decoder.cpp:213)
==14132==    by 0x7FC4D75: CSubband::PlaceTile(CDecoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:227)
==14132==    by 0x7FBF69D: CPGFImage::Read(int, bool (*)(double, bool, void*),
void*) (PGFimage.cpp:286)

==14132==
==14132== Conditional jump or move depends on uninitialised value(s)
==14132==    at 0x7FBC21E: CDecoder::RLDSigsAndSigns(unsigned int, unsigned
int, unsigned int*, unsigned int*) (Decoder.cpp:699)
==14132==    by 0x7FBC911: CDecoder::BitplaneDecode(unsigned int)
(Decoder.cpp:536)
==14132==    by 0x7FBCAA9: CDecoder::DecodeBuffer() (Decoder.cpp:451)
==14132==    by 0x7FBCB41: CDecoder::DequantizeValue(CSubband*, unsigned int,
int) (Decoder.cpp:394)
==14132==    by 0x7FBD036: CDecoder::Partition(CSubband*, int, int, int, int,
int) (Decoder.cpp:213)
==14132==    by 0x7FC4D75: CSubband::PlaceTile(CDecoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:227)
==14132==    by 0x7FBF69D: CPGFImage::Read(int, bool (*)(double, bool, void*),
void*) (PGFimage.cpp:286)

And when the reader bug is fixed (and the image is indeed invalid), the next
bug to hunt is in the writer, when these images are created ;-)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #12 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-05-30 21:53:33 ---
As a hint for the writer bug: valgrind gives the following eight errors when
saving a PGF.
Uninitialized value problems tend to work in 99% of cases but break for the
rest (could explain this bug is rarely seen)

==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A6813: CEncoder::RLESigsAndSigns(unsigned int*, unsigned
int, unsigned int*, unsigned int) (BitStream.h:203)
==28252==    by 0x80A7054: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:380)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A7461: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:253)
==28252==    by 0x80A7544: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:152)
==28252==    by 0x80AE01D: CSubband::ExtractTile(CEncoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:188)
==28252==    by 0x80A956C: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:922)

==28252==
==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A686A: CEncoder::RLESigsAndSigns(unsigned int*, unsigned
int, unsigned int*, unsigned int) (Encoder.cpp:628)
==28252==    by 0x80A7054: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:380)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A7461: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:253)
==28252==    by 0x80A7544: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:152)
==28252==    by 0x80AE01D: CSubband::ExtractTile(CEncoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:188)
==28252==    by 0x80A956C: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:922)

==28252==
==28252== Syscall param write(buf) points to uninitialised byte(s)
==28252==    at 0xBA6131D: ??? (in /lib64/libpthread-2.11.3.so)
==28252==    by 0x80AD921: CPGFFileStream::Write(int*, void*)
(PGFplatform.h:510)
==28252==    by 0x80A7352: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:311)
==28252==    by 0x80A7461: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:253)
==28252==    by 0x80A7544: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:152)
==28252==    by 0x80AE01D: CSubband::ExtractTile(CEncoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:188)
==28252==    by 0x80A956C: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:922)
==28252==  Address 0x359a3b35 is on thread 5's stack


==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A6AB6: CEncoder::RLESigns(unsigned int*, unsigned int)
(BitStream.h:233)
==28252==    by 0x80A7133: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:418)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A7461: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:253)
==28252==    by 0x80A7544: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:152)
==28252==    by 0x80AE01D: CSubband::ExtractTile(CEncoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:188)
==28252==    by 0x80A963B: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:932)

==28252==
==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A6A9C: CEncoder::RLESigns(unsigned int*, unsigned int)
(BitStream.h:233)
==28252==    by 0x80A7133: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:418)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A7461: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:253)
==28252==    by 0x80A7544: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:152)
==28252==    by 0x80AE01D: CSubband::ExtractTile(CEncoder&, int, bool, unsigned
int, unsigned int) (Subband.cpp:188)
==28252==    by 0x80A966F: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:933)

==28252==
==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A6813: CEncoder::RLESigsAndSigns(unsigned int*, unsigned
int, unsigned int*, unsigned int) (BitStream.h:203)
==28252==    by 0x80A7054: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:380)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A76BC: CEncoder::Flush() (Encoder.cpp:216)
==28252==    by 0x80A96D1: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:953)

==28252== Conditional jump or move depends on uninitialised value(s)
==28252==    at 0x80A686A: CEncoder::RLESigsAndSigns(unsigned int*, unsigned
int, unsigned int*, unsigned int) (Encoder.cpp:628)
==28252==    by 0x80A7054: CEncoder::BitplaneEncode(unsigned int)
(Encoder.cpp:380)
==28252==    by 0x80A72F7: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:274)
==28252==    by 0x80A76BC: CEncoder::Flush() (Encoder.cpp:216)
==28252==    by 0x80A96D1: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:953)

==28252== Syscall param write(buf) points to uninitialised byte(s)
==28252==    at 0xBA6131D: ??? (in /lib64/libpthread-2.11.3.so)
==28252==    by 0x80AD921: CPGFFileStream::Write(int*, void*)
(PGFplatform.h:510)
==28252==    by 0x80A7352: CEncoder::EncodeBuffer(ROIBlockHeader)
(Encoder.cpp:311)
==28252==    by 0x80A76BC: CEncoder::Flush() (Encoder.cpp:216)
==28252==    by 0x80A96D1: CPGFImage::Write(CPGFStream*, int, bool (*)(double,
bool, void*), unsigned int*, void*) (PGFimage.cpp:953)
==28252==    by 0x7EE1544: Digikam::PGFLoader::save(QString const&,
Digikam::DImgLoaderObserver*) (pgfloader.cpp:438)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Raphael Schweizer
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #13 from Raphael Schweizer <rschweizer schweizer-informatik ch>  2011-06-06 11:35:15 ---
Currently there is ongoing work on a new, slightly 'OMP'ified, version of the
codec which does not contain anymore the notorious CEncoder::RLESigsAndSigns
method.
So, contradictory to "we [...] provide a patch shortly", there will be no
prompt fix, unless you have objections.

Marcel, could you also provide the source image for
http://digikam3rdparty.free.fr/TEST_IMAGES/PGF/DSC03274_v1.pgf ? Was this image
converted using digikam without any obvious errors? We never had any signs of
libPGF encoding sane images into corrupted PGF images.
And also "converting .nef in batch resize+pgf does not give byte exact
files if run twice there are usually at least 3 or 4 bytes that differ" sounds
strange, as PGF really should be deterministic.
Francesco, could you check whether this is PGF or the batch resize? I.e.
whether the resized pictures always are byte-equal?

- Raphael

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #14 from Francesco Riosa <francesco+kde pnpitalia it>  2011-06-06 16:53:12 ---
(In reply to comment #13)

> [SNIP]
> And also "converting .nef in batch resize+pgf does not give byte exact
> files if run twice there are usually at least 3 or 4 bytes that differ" sounds
> strange, as PGF really should be deterministic.
> Francesco, could you check whether this is PGF or the batch resize? I.e.
> whether the resized pictures always are byte-equal?
>
> - Raphael

I've tried batch resize+PNG and it give two different images if run twice,
probably somewhere between raw converter and resizer there is some random value
added nothing too worrysome and
PGF encoder has nothing to do with that

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa-2
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #15 from Francesco Riosa <francesco+kde pnpitalia it>  2011-06-06 16:57:21 ---
> - Raphael

also, just out of curiosity, have you considered orc, successors of liboil
(http://code.entropywave.com/projects/orc/)
it claim to make easy to optimize operations on contiguous arrays, only because
you mentioned "omp"ification

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Raphael Schweizer
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #16 from Raphael Schweizer <rschweizer schweizer-informatik ch>  2011-06-06 17:48:35 ---
Francesco,

thanks for checking (glad we don't have to deal with unintended randomness in
PGF).
Orc looks like an interesting approach (having dealt with SSE intrinsics,
making them more abstract is tempting). However, I don't think we will see Orc
code within libPGF anytime soon. Windows users are not as used to complicated
build processes as others are, and Orc's instructions (respectively the lack of
WIN related ones) look frightening. Also, my test results / benchmarks using
SSE are not very encouraging. Extrapolating them could make AVX interesting,
though. But this would require a major remake of most array intensive code in
libPGF, while still maintaining compatibility with older CPUs.

- Raphael

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #17 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-06-07 21:16:51 ---
Yes I have the source, but I could not reproduce an image that crashes. At this
one day, I produced three images that crashed; since then, none has. The source
are normal JPG images, some filters were applied. Nothing special in that
regard.

What I can reproduce are the uninitialized-value errors. (As I said, it would
be well possible that an uninitialized memory area is almost always as
expected. I once found the status of uninitialized memory very much
reproducible)
They may just as well be completely misleading though.
I would guess that refBits and signBits are not set to 0; I cannot judge if
this is relevant.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Raphael Schweizer
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #18 from Raphael Schweizer <rschweizer schweizer-informatik ch>  2011-06-09 19:24:10 ---
Thank you very much. There's another new report of indeterminism
(http://sourceforge.net/projects/libpgf/forums/forum/530086/topic/4566988),
possibly due to padding w/ uninitialized buffers. I'll definitely look into
this once more and make sure this is solved for the next release.

- Raphael

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Marcel Wiesweg
In reply to this post by Francesco Riosa-2
https://bugs.kde.org/show_bug.cgi?id=273765





--- Comment #19 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-06-11 16:40:44 ---
And you will surely also fix the crash when reading the invalid file (instead,
failing to load it)? ;-)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
1234