Bug 1302879 - strigita_torrent_analyzer causes deepgrep to crash
strigita_torrent_analyzer causes deepgrep to crash
Product: Fedora
Classification: Fedora
Component: kdenetwork-strigi-analyzers (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-01-28 16:17 EST by Göran Uddeborg
Modified: 2016-05-03 15:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-03 15:18:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 358752 None None None 2016-01-29 17:18 EST

  None (edit)
Description Göran Uddeborg 2016-01-28 16:17:15 EST
Description of problem:
After installing kdenetwork-strigi-analyzers crashes immediately on invocation.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. deepgrep xyz .

Actual results:
Segmentation violation crash (with core dump if enabled).

Expected results:
No crash.

Additional info:
Let me know if this is more appropriately reported upstreams.  I can do that, but I wanted to make sure it wasn't something Fedora specific before I do.

See below for the backtrace of the crash.  I tried to understand what is wrong, but ended up in a "how could this possibly have worked" situation instead.  

In StreamAnalyzerPrivate::analyze (in the strigi code) a loop is executed as long as "input" is 0 or one other case.  So here clearly input==0 is expected.  Then connectInputStream(input) is called on the iterated object, in this case a TorrentThroughAnalyzer.

In TorrentThroughAnalyzer.connectInputStream() a ByteStream object is created from the (possibly 0) "input", and a prefix ++ operator is called on it.  ByteStream initializes its "m_input" member directly from the argument.  Then the prefix ++ operator is called on that new stream.

ByteStream::operator++() calls refillBuffer if the "m_buffer" element is zero, which it will be since it was just initialized to zero on stream creation.

And in ByteStream::refillBuffer() the member function read() of "m_input" is called.  As "m_input" is still zero, I can't see how this ever could have worked.  C++ can do many strange things under the hood, and I've been fooled before.  But surely, a call of a virtual member function requires a valid object pointer, doesn't it?

#0  0x00007f507af7521a in ByteStream::refillBuffer (this=0x7ffe980a4470) at ../../torrent/bytestream.cpp:63
#1  0x00007f507af7533d in ByteStream::operator++ (this=this@entry=0x7ffe980a4470) at ../../torrent/bytestream.cpp:54
#2  0x00007f507af784e7 in TorrentThroughAnalyzer::connectInputStream (this=0x5587521e03e0, input=0x0) at ../../torrent/torrent_analyzer.cpp:74
#3  0x00007f507ce28732 in Strigi::StreamAnalyzerPrivate::analyze (this=0x558752225af0, idx=..., input=input@entry=0x0) at /usr/src/debug/strigi-0.7.8/libstreamanalyzer/lib/streamanalyzer.cpp:392
#4  0x00007f507ce290d8 in Strigi::StreamAnalyzer::analyze (this=<optimized out>, idx=..., input=input@entry=0x0) at /usr/src/debug/strigi-0.7.8/libstreamanalyzer/lib/streamanalyzer.cpp:359
#5  0x00007f507ce03228 in Strigi::AnalysisResult::index (this=this@entry=0x7ffe980a4600, file=file@entry=0x0) at /usr/src/debug/strigi-0.7.8/libstreamanalyzer/lib/analysisresult.cpp:235
#6  0x00007f507ce0929a in Strigi::DirAnalyzer::Private::analyzeFile (this=this@entry=0x5587521ddef0, path=..., mtime=1449744713, realfile=<optimized out>) at /usr/src/debug/strigi-0.7.8/libstreamanalyzer/lib/diranalyzer.cpp:111
#7  0x00007f507ce09f37 in Strigi::DirAnalyzer::Private::analyzeDir (this=0x5587521ddef0, dir=..., nthreads=8, c=<optimized out>, lastToSkip=...) at /usr/src/debug/strigi-0.7.8/libstreamanalyzer/lib/diranalyzer.cpp:254
#8  0x00005587502f0a69 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/strigi-0.7.8/strigiutils/bin/deepfind/deepgrep.cpp:82
Comment 1 Rex Dieter 2016-01-29 09:16:40 EST
Upstream is probably the way to go, yeah, though I'm having trouble finding how to do that exactly (bugs.kde.org currently has no strigi-related components), and it's continuing maintenance future (this module may get dropped/unsupported upstream soon).

In the meantime, I can confirm the mere presence of this strigi plugin can cause crashes, so I guess my only best recommendation is to uninstall this to avoid the crashes.
Comment 2 Göran Uddeborg 2016-01-29 17:22:03 EST
I also couldn't find any appropriate place for this report on the KDE side.  Since you know KDE way better than I do, I didn't have much hope in the first place, but I did a try anyway.

But now I've reported it in a general category, I hope they someone will be able to move it to a more appropriate product and category.
Comment 3 Rex Dieter 2016-05-03 15:18:00 EDT
Will continue to track this upstream, thanks.

Note You need to log in before you can comment on or make changes to this bug.