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 437322 - beagled-helper uses 100% CPU indexing null .mp3 files
beagled-helper uses 100% CPU indexing null .mp3 files
Status: RESOLVED FIXED
Product: beagle
Classification: Other
Component: General
0.2.16
Other Linux
: Normal normal
: ---
Assigned To: Beagle Bugs
Beagle Bugs
Depends on:
Blocks:
 
 
Reported: 2007-05-10 01:08 UTC by Dooglus
Modified: 2007-05-10 04:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dooglus 2007-05-10 01:08:18 UTC
Downloading large mp3 files using bittorrent causes beagled-helper to get stuck using lots of CPU time.

I'm using Azureus.  It pre-allocates the mp3 file with lots of zero bytes, which seems to cause trouble for beagled-helper.

To reproduce the problem, run this command somewhere that beagle indexes:

  dd if=/dev/zero of=zero.mp3 bs=1000 count=10000

This makes a 96M file full of zeros.

Running strace on beagled-helper shows that it's doing the following:

_llseek(31, 39540358, [39540358], SEEK_SET) = 0
read(31, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
fstat64(31, {st_mode=S_IFREG|0644, st_size=100000000, ...}) = 0
_llseek(31, 39540359, [39540359], SEEK_SET) = 0
read(31, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
fstat64(31, {st_mode=S_IFREG|0644, st_size=100000000, ...}) = 0
_llseek(31, 39540360, [39540360], SEEK_SET) = 0
read(31, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
fstat64(31, {st_mode=S_IFREG|0644, st_size=100000000, ...}) = 0
_llseek(31, 39540361, [39540361], SEEK_SET) = 0
read(31, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
fstat64(31, {st_mode=S_IFREG|0644, st_size=100000000, ...}) = 0
_llseek(31, 39540362, [39540362], SEEK_SET) = 0
read(31, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
fstat64(31, {st_mode=S_IFREG|0644, st_size=100000000, ...}) = 0

notice that the llseek offset is increased by one each time.  I guess it's trying to find the ID3 header at every location within the file, and using a lot of CPU time in the process.
Comment 1 Debajyoti Bera 2007-05-10 04:12:13 UTC
Beagle switched to taglib-sharp (from entagged-sharp) which handles this case without any problem. To test, sync to svn trunk r3706.