GNOME Bugzilla – Bug 676934
Library scan suddenly hogs all available RAM and swap space.
Last modified: 2018-08-17 19:49:15 UTC
Steps to reproduce: * be prepared to "killall banshee" in a terminal * copy the attached file to banshee music library folder * start a manual library rescan Observed: * banshee suddenly hogs all RAM ans starts swapping until it is closed or killed * library scan is stalled, OS becomes very unresponsive. Using Banshee 2.4.0 on ubuntu 12.04. Tried Banshee daily build from ubuntu PPA, with the same results.
Note that Rhythmbox scans and plays the attached track normally.
Could not attach file. Please download it from here: http://ubuntuone.com/7grLnzaUOsIUzkXJMcxuNn
Thanks for your bug report. Changing status from UNCONFIRMED to NEW because I could reproduce it.
I think the problem is with taglib-sharp Here's the stacktrace I was able to grab while Banshee was eating my RAM: "Threadpool worker" tid=0x0x2aab0c401700 this=0x0x2aaab7407138 thread handle 0x63f state : interrupted state owns () at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <IL 0x0000e, 0xffffffff> at GLib.GioStream.Read (byte[],int,int) <IL 0x000e0, 0x001c3> at TagLib.File.ReadBlock (int) <IL 0x00040, 0x000c0> at TagLib.Mpeg4.Box.LoadData (TagLib.File) <IL 0x00024, 0x0004b> at TagLib.Mpeg4.UnknownBox..ctor (TagLib.Mpeg4.BoxHeader,TagLib.File,TagLib.Mpeg4.IsoHandlerBox) <IL 0x0001c, 0x0006f> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox,int) <IL 0x00245, 0x00e4f> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,long,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox,int) <IL 0x0000f, 0x000f7> at TagLib.Mpeg4.Box.LoadChildren (TagLib.File) <IL 0x0004d, 0x000f7> at TagLib.Mpeg4.IsoMetaBox..ctor (TagLib.Mpeg4.BoxHeader,TagLib.File,TagLib.Mpeg4.IsoHandlerBox) <IL 0x0000c, 0x00067> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox,int) <IL 0x00180, 0x00953> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,long,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox,int) <IL 0x0000f, 0x000f7> at TagLib.Mpeg4.Box.LoadChildren (TagLib.File) <IL 0x0004d, 0x000f7> at TagLib.Mpeg4.IsoUserDataBox..ctor (TagLib.Mpeg4.BoxHeader,TagLib.File,TagLib.Mpeg4.IsoHandlerBox) <IL 0x0001c, 0x0006f> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox,int) <IL 0x00167, 0x0089b> at TagLib.Mpeg4.BoxFactory.CreateBox (TagLib.File,TagLib.Mpeg4.BoxHeader,TagLib.Mpeg4.IsoHandlerBox) <IL 0x00009, 0x000c3> at TagLib.Mpeg4.FileParser.ParseTagAndProperties (long,long,TagLib.Mpeg4.IsoHandlerBox,System.Collections.Generic.List`1<TagLib.Mpeg4.BoxHeader>) <IL 0x00158, 0x00627> at TagLib.Mpeg4.FileParser.ParseTagAndProperties (long,long,TagLib.Mpeg4.IsoHandlerBox,System.Collections.Generic.List`1<TagLib.Mpeg4.BoxHeader>) <IL 0x00049, 0x00157> at TagLib.Mpeg4.FileParser.ParseTagAndProperties () <IL 0x0001f, 0x0004f> at TagLib.Mpeg4.File.Read (TagLib.ReadStyle) <IL 0x0002b, 0x000a3> at TagLib.Mpeg4.File..ctor (TagLib.File/IFileAbstraction,TagLib.ReadStyle) <IL 0x00014, 0x0005b> at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object_int (object,intptr,intptr,intptr) <IL 0x0005e, 0xffffffff> at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) <IL 0x0001c, 0xffffffff> at System.Reflection.MonoCMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <IL 0x00124, 0x001cf> at System.Reflection.MonoCMethod.Invoke (System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <IL 0x00007, 0x0003d> at System.Activator.CreateInstance (System.Type,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[]) <IL 0x00186, 0x002ef> at System.Activator.CreateInstance (System.Type,object[],object[]) <IL 0x0000a, 0x00037> at System.Activator.CreateInstance (System.Type,object[]) <IL 0x00002, 0x0002f> at TagLib.File.Create (TagLib.File/IFileAbstraction,string,TagLib.ReadStyle) <IL 0x00113, 0x002d3> at Banshee.IO.DemuxVfs.OpenFile (string,string,TagLib.ReadStyle) [0x00000] in /home/lorentz/Projets/banshee/src/Core/Banshee.Core/Banshee.IO/DemuxVfs.cs:38 at Banshee.Streaming.StreamTagger.ProcessUri (Hyena.SafeUri) [0x00000] in /home/lorentz/Projets/banshee/src/Core/Banshee.Core/Banshee.Streaming/StreamTagger.cs:48 at Banshee.Collection.Database.DatabaseImportManager.ImportTrack (Hyena.SafeUri) [0x00061] in /home/lorentz/Projets/banshee/src/Core/Banshee.Services/Banshee.Collection.Database/DatabaseImportManager.cs:178 at Banshee.Collection.Database.DatabaseImportManager.ImportTrack (string) [0x00000] in /home/lorentz/Projets/banshee/src/Core/Banshee.Services/Banshee.Collection.Database/DatabaseImportManager.cs:156 at Banshee.Collection.Database.DatabaseImportManager.OnImportRequested (string) [0x00000] in /home/lorentz/Projets/banshee/src/Core/Banshee.Services/Banshee.Collection.Database/DatabaseImportManager.cs:130 at Banshee.Collection.ImportManager/ImportElement.ProcessItem (string) [0x00024] in /home/lorentz/Projets/banshee/src/Core/Banshee.Services/Banshee.Collection/ImportManager.cs:67 at Hyena.Collections.QueuePipelineElement`1.Processor (object) [0x0009d] in /home/lorentz/Projets/banshee/src/Hyena/Hyena/Hyena.Collections/QueuePipelineElement.cs:153 at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <IL 0x00052, 0xffffffff>
I tested this again today (with git master and 2.4.0), and to my surprise I cannot reproduce it anymore! :( ricflomag: did you change the file that is hosted in the ubuntuone link you provided? Bertrand: can you test again? if you don't reproduce it either, by any chance do you still have the problematic file?
Andrés: the file on ubuntuone has not changed. I have just reproduced the bug here on ubuntu 12.04 using the stock banshee.
Thanks, that is definitely very weird, I have already tried to reproduce it again with 2 versions of banshee in 2 different OSs...
I can reproduce this. We consume 800mb of memory loading this file. Will hopefully get this fixed today.
Thanks Alan, I was aiming to look at this too but sadly I couldn't reproduce it again... :(
The file itself is corrupt or malformed. The mpeg4 header tree contains an item which says it is 800mb in size. I loaded this file in AtomicParsley for independent verification of this and AtomParsley handles this situation by clamping the data size to be the length of the file. While we *could* do this too, the result would be that if you load this file, edit a tag and then save it, you will double the size of your file as we would write out that broken tag with the full data (the length of the file). As such, we are probably just going to throw a parsing exception if there are any tags which require us to read more data than exists in the file itself. Finally, how did you create this file? Maybe if we had access to a few more files made by the same encoder we would be able to figure out what has gone wrong and work around it in a reliable manner.
ricflomag: can you answer to last paragraph of comment 10? Switching bug to taglib-sharp then. Alan: I think throwing a parsing exception is fine so long as Banshee doesn't crash when reading. I'm assuming the user may be able to fix the corrupted data when saving metadata back again from banshee? Or will taglib-sharp throw an exception too?
Here is another file that triggers the bug: http://ubuntuone.com/6O8avj5XQDxcXg5LQ34M02 (sorry for the title of the track) Each of these files takes me half an hour to identify, as I have to go through a trial-and-error process of narrowing the set of tracks I make Banshee scan. Quite boring actually ;) I'm afraid I can't help with the name of the encoder used, as these files come from a folder containing 25Gb of music from different sources, in a friend's computer. Before installing Ubuntu, she used a deprecated version of iTunes under windows, but I can't say if she encoded those files with it or just downloaded them from the Internet.
taglib-sharp has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/mono/taglib-sharp/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.