After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 542582 - beagle-helper hangs with 100% cpu on incomplete mpeg files
beagle-helper hangs with 100% cpu on incomplete mpeg files
Status: RESOLVED WONTFIX
Product: beagle
Classification: Other
Component: General
0.3.x
Other All
: Normal major
: ---
Assigned To: Beagle Bugs
Beagle Bugs
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-07-11 20:14 UTC by Philip Van Baren
Modified: 2018-07-03 09:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Van Baren 2008-07-11 20:14:33 UTC
Please describe the problem:
When beagled is using its internal "FilterVideo" filter, it frequently gets stuck in an infinite loop when processing mpeg video files.  Normally you don't run into this problem because the "FilterMPlayerVideo" is usually used, but if mplayer is not installed on the system, then it falls back to "FilterVideo", and hangs.

Steps to reproduce:
1. Remove mplayer from your system (or temporarily disable it)
2. Put a corrupt .mpeg video file in the directory beagle is indexing
3. Let beagled start indexing

You can also reproduce this running beagle-extract-content on the corrupt file


Actual results:
beagled-helper hangs trying to filter the corrupt mpeg file, using 100% cpu indefinitely.  This prevents beagle from indexing any further, because it is stuck on this file.  If I remove the corrupt file, shutdown, and restart beagled, then it will proceed until it runs into the next corrupt file.

Expected results:
beagled-helper should give up processing the file once it can't find the information it is looking for (width and height I assume)

Does this happen every time?
This happens every time for corrupt or incomplete mpeg files

Other information:
The problem is an infinite loop in Filters/TagLib/Mpeg/File.cs  ReadVideoPacket function

Here is a version of that function which prevents the infinite loop:

void ReadVideoPacket (ref long position)
{
    Seek (position + 4);
    int length = ReadBlock (2).ToUShort ();
    long offset = position + 6;
    // Put a sanity limit on how long we search
    int sanity_limit = 1000;
    int i=0;

    while (!video_found && (i < sanity_limit) && offset < position + length) {
        if (FindMarker (ref offset) ==
            Marker.VideoSyncPacket) {
            video_header = new VideoHeader (this,
                offset + 4);
            video_found = true;
        } else {
            // Make sure we keep moving forward, because this one didn't match
            offset += 4;
        }
        i++;
    }

    position += length;
}
Comment 1 Debajyoti Bera 2008-07-11 22:23:45 UTC
Yes. Thanks for reporting this. I came to know this problem recently. I was not able to reach TagLib# author. Yesterday I also filed a bug with banshee because they too have the same problem.

BTW, I dont think there is any "infinite loop". Its just that the whole file is read byte-by-byte.

We have dropped our copy of taglib-sharp and instead depend on an external taglib-sharp.dll packaged library. So we cannot fix this in beagle the way you describe above. Moreover this problem exists in (almost) all their file readers - they keep reading till the marker is found. Taglib-sharp almost certainly needs to handle corrupt files better.

If you can hunt down taglib-sharp bugzilla and file a bug there, that will be extremely useful. I couldn't find any active taglib-sharp bugzilla.

I will keep this open till the taglib-sharp problem is solved or we find a correct workaround in beagle.
Comment 2 André Klapper 2018-07-03 09:51:38 UTC
Beagle is not under active development anymore and had its last code changes in early 2011. Its codebase has been archived (see bug 796735):
https://gitlab.gnome.org/Archive/beagle/commits/master

"tracker" is an available alternative.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the
responsibility for active development again.