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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |