[KimDaBa] Strange crash with KimDaBa and SUSE 9.1 with KDE 3.3.2

[Robert L Krawitz]

I'm having a seg fault with the above-mentioned configuration when I
try to load a TIFF file.  It didn't happen when I was running 3.3.1;
it's when I upgraded to the 3.3.2 RPM's that this started to happen.
It doesn't always happen (I don't have a repeatable test case, but
trying enough times eventually causes it to happen), but it seems to
happen more often with big files (and I have some *really* big TIFF
files -- 110 MB scans).  Sometimes it doesn't crash, but it also
doesn't load the image (the image comes out blank), and sometimes it
does load the image.

#0  0x41a5f730 in putRGBAAcontig8bittile () from /usr/lib/libtiff.so.3
#1  0x41a65ea5 in gtStripContig () from /usr/lib/libtiff.so.3
#2  0x41a61471 in TIFFRGBAImageGet () from /usr/lib/libtiff.so.3
#3  0x41a65684 in TIFFReadRGBAImageOriented () from /usr/lib/libtiff.so.3
#4  0x41a656f2 in TIFFReadRGBAImage () from /usr/lib/libtiff.so.3
#5  0x4200b311 in kimgio_tiff_read () from /opt/kde3/lib/kde3/kimg_tiff.so
#6  0x4025ba8b in KImageIOFormat::callLibFunc () from /opt/kde3/lib/libkio.so.4
#7  0x4025cc2e in KImageIOFactory::readImage () from /opt/kde3/lib/libkio.so.4
#8  0x40bd5e27 in QImageIO::read () from /usr/lib/qt3/lib/libqt-mt.so.3
#9  0x40bd82bb in QImage::load () from /usr/lib/qt3/lib/libqt-mt.so.3
#10 0x08074880 in ImageLoader::run ()
#11 0x40b9b185 in QThreadInstance::start () from /usr/lib/qt3/lib/libqt-mt.so.3
#12 0x412bb201 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x412bb27f in pthread_start_thread_event () from /lib/libpthread.so.0
#14 0x414c9ffa in clone () from /lib/libc.so.6

This looks like a "this shouldn't happen" kind of thing.  It happens
whether I compile with optimization on or off.  It happens if the
Util::isJPEG() test in ImageLoader::run() fails, and goes through the
standard path.  This doesn't happen when using gwenview or kview.
What's really interesting is that if I insert a simple debug statement
right before the img.load() the problem at least seems to go away
(i. e. I was able to build thumbnails -- many hundreds of them -- and
view images without a problem):

            if ( !imageLoaded && QFile( li.fileName() ).exists() ) {
                if (Util::isJPEG(li.fileName())) {
                    QSize fullSize;
                    Util::loadJPEG(&img, li.fileName(),  &fullSize, li.width(), li.height());
                    li.setFullSize( fullSize );
                } else {
>>>>>		  kdDebug() << "Loading |" << li.fileName() << "|" << endl;
                    img.load( li.fileName() );
                    li.setFullSize( img.size() );
                }

However, if the debug statement looks like this:

		  kdDebug() << "Loading" << li.fileName() << endl;

the problem is still there.

This suggests to me that there's a thread synchronization or MT memory
management problem of some kind, since the behavior's not perfectly
reproducible, it happens inside a single (from the program's point of
view) place using stable library code (although it changed with an
upgrade between two stable versions), and the behavior changes
depending upon something else that likely has side effects.

I'm trying to run it under valgrind, but that's going to take ages,
even now that I've reloaded my fast machine 32-bit (so that valgrind
will work).  Last time I tried it I didn't get anywhere, because
valgrind seems to have trouble with multithreaded software.  I'm also
going to try Electric Fence.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton