Peter Fritzsche wrote:
> Package: libstreamanalyzer0
> Version: 0.7.1-1
> Severity: important
> I tried to get more information for #571721 directly from strigi-daemon,
> but it only crashes somewhere else without any further information which
> file was the problem.
I did some tests with xmlindexer -j 1 and noticed that it only happens when
having two compressed files after each other. One is called s.tar.lzma and the
other one u.tar.bz2. They contain both nearly the same content (customized
debian based usermode linux root image and some scripts to use it). It crashes
when the bz2 is indexed after the lzma, but _not_ when the lzma is scanned
after the bz2.
So I duplicated the lzma and the bz2 in two different paths and started to
scan them again. Two lzmas didn't cause a crash, but two bz2 crashed.
Next step I recompressed the lzma tarball to bz2 and tried again. It didn't
crashed everything as expected. So decompressed the old bz2 and recompressed
again as bz2. This recompressed u.tar.bz2 and the u2.tar.bz2 still created the
crash. Next idea is to use the uncompressed tar u.tar and u2.tar. This time
the same crash happened - ok, the backtrace looks a little bit different:
#0 0x0000003a3ec1a549 in Strigi::ArInputStream::checkHeader (data=<value
optimized out>, datasize=<value optimized out>) at
#1 0x0000003a3e839e1d in Strigi::StreamAnalyzerPrivate::analyze (this=<value
optimized out>, idx=<value optimized out>,
input=<value optimized out>)
#2 0x0000003a3e81f6f4 in Strigi::DirAnalyzer::Private::analyze (this=<value
optimized out>, analyzer=<value optimized out>)
#3 0x0000003a3e81fc06 in Strigi::DirAnalyzer::Private::analyzeDir (this=<value
optimized out>, dir=<value optimized out>,
nthreads=<value optimized out>, c=<value optimized out>,
lastToSkip=<value optimized out>) at
#4 0x0000000000404afa in main (argc=<value optimized out>, argv=<value
optimized out>) at
So, I uncompressed u and u2 and checked again. This time it didn't crash.
So my I would guess that it is related to the tarball. I am a little bit
clueless how to proceed further.
So played a little bit more around and decompressed the tarball with
"tar xvfSp" (as root) and recompressed everything as "tar xvfSp" (as root).
This time it started to crash again. So I removed the biggest file in the
tarball (root.img) and then recompressed it and copied it to u2.tar this
time it didn't crash anymore. So it is probably related to the root.img.
So removed the new tarballs and decompressed the old u.tar, removed everything
but the root.img, recompressed and duplicated u.tar. This time it crashed
again. So the biggest file it the problem.... which is quite problematic
when I want to attach it to a bug report - next test is to reduce the
size of the root.img, but first a check if the crash is related to the
Sparse tarball by rewriting the file with `dd if=root.img of=root2.img` and
then renaming it from root2.img to root.img). This time it didn't crashed....
So checking it again by copying it back using
`cp --sparse=always root2.img root.img; rm root2.img`.
It crashed again. So it is maybe possible to reduce the size of the image.
Did it with following script:
rm -f *.tar
sudo tar xvfSp ../u.tar
dd if=root.img of=root2.img skip=78438 count=203706
cp --sparse=always root2.img root.img
sudo tar cvfSp u.tar umlnetwork
rm -rf umlnetwork
cp u.tar u2.tar
xmlindexer -j 1
I did some tests and i cannot reproduce the bug all the time. Sometimes
it runs without any problems and sometimes it crashes.
I think it crashed more often with the large archive, but I
dont have enough webspace to upload the large version. Just download
it in a new directory using
wget http: // mitglied.multimania .de/ robertwohlrab/u.tar.xz # remove the
whitespaces - otherwise the spamfilter didn't
accept the mail
cp u.tar u2.tar
xmlindexer -j 1 # had to run ~5 times before i got the first crash
I couldn't reproduce the crash when I started it with valgrind (also not
with the big file).
pkg-kde-extras mailing list