Bug 303286

Summary: kfilemetadatareader hogs all memory and cpu
Product: [Unmaintained] kdelibs Reporter: harri
Component: generalAssignee: Jos van den Oever <jos>
Status: RESOLVED FIXED    
Severity: major CC: adaptee, faure, kdelibs-bugs, nate
Priority: NOR Keywords: testcase
Version: 4.8.4   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: corrupted wav file that can be used to reproduce the problem

Description harri 2012-07-10 09:39:05 UTC 
Running kubuntu 12.04 amd64, KDE 4.8.4

I've been recently working with audio files with bad metadata.  

kfilemetadatareader seems to be launched by dolphin, and regularly my machine was falling on its knees, with multiple kfilemetadatareader processesses hogging 100% and 4+ Gb of memory each (I have 16 Gb).

I've attached a sample wav file 

kfilemetadatareader --file kfilemetadatacrasher.wav

illustrates the problem.  
It never returns, use Ctrl-C to kill before out of memory.




Reproducible: Always

Steps to Reproduce:
1. wget http://mpaja.com/download/kfilemetadatacrasher.wav
2. kfilemetadatareader --file kfilemetadatacrasher.wav
3. CPU goes 100%, memory usage grows steadily.   Use Ctrl-C to break.
Actual Results:  
Out of memory

Expected Results:  
Ideally a report that file metadata seems corrupted.
In the minimum should exit without hogging the machine.

I'd categorize this as major bug, as Dolphin launches multiple instances of kfilemetadatareader without prompting the user. When machine slows to crawl it is unobvious what caused it, and by that time it is hard to find out as machine is unresponsive.
Comment 1 harri 2012-07-10 09:41:22 UTC 
Created attachment 72422 [details]
corrupted wav file that can be used to reproduce the problem
Comment 2 David Faure 2012-07-16 12:14:44 UTC 
The bug is in strigi/libstreamanalyzer/plugins/eventplugins/riffeventanalyzer.cpp

pos goes up to 44 (8 by 8), and then this code runs:

350│             handleChunkData(offset + pos, data + pos, length - pos);
351│             uint32_t fp = chunks.top().start + chunks.top().size;
352│             if (fp <= offset + length) {
353├>                pos = fp - offset;

At this point, fp is 0, and offset is 0, so "pos" goes back to 0, and all this starts all over again.

This needs someone with actual knowledge of the file format, to know what to spot as the actual cause for aborting. Maybe "pos" should never go back? Or maybe it can happen in some valid cases?
Comment 3 Christoph Feck 2012-08-31 17:33:04 UTC 
*** Bug 306019 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2020-09-28 21:34:14 UTC 
*** Bug 306019 has been marked as a duplicate of this bug. ***
Comment 5 Nate Graham 2020-09-28 21:34:54 UTC 
No longer relevant in the Baloo era.