GNOME Bugzilla – Bug 609850
tracker-store segfault in tracker_parser_process_word
Last modified: 2010-03-05 17:25:57 UTC
After upgrading to tracker 0.7.20 on my Mandriva Cooker system (using latest GNome 2.29.x), I found a core file generated by tracker-store on my system. Core was generated by `/usr/lib64/tracker-store'. Program terminated with signal 11, Segmentation fault.
+ Trace 220558
Thread 1 (Thread 3635)
(In reply to comment #0) > After upgrading to tracker 0.7.20 on my Mandriva Cooker system (using latest > GNome 2.29.x), I found a core file generated by tracker-store on my system. > > Core was generated by `/usr/lib64/tracker-store'. > Program terminated with signal 11, Segmentation fault. > Hi, This is a known bug with libunac. If that is disabled in the build, it doesn't crash. When parsing a string with non-ascii characters, like föö, it should return "foo" and it does. However, it corrupts the stack somehow. For now we are advising libunac is disabled unless a newer version than I am using here fixes this (1.8.0-2 on Ubuntu).
(In reply to comment #1) > (In reply to comment #0) > This is a known bug with libunac. If that is disabled in the build, it doesn't > crash. When parsing a string with non-ascii characters, like föö, it should > return "foo" and it does. However, it corrupts the stack somehow. For now we > are advising libunac is disabled unless a newer version than I am using here > fixes this (1.8.0-2 on Ubuntu). Hey Martyn, Do you have more info on this memory corruption in libunac? Do they have a bug open about this?
(In reply to comment #2) > Hey Martyn, Hej, > Do you have more info on this memory corruption in libunac? Not really, I did try to fix it and it didn't seem quick to fix and I couldn't get the package from ubuntu to build for me initially so I gave up on it until we had more time for it. I am pretty sure it corrupts the stack because the one API call changes the TrackerParser pointer and without that call, we don't have a problem. Looking at their source they do some funky stuff with strings and memory so we just need to invest time to make sure their code isn't broken. > Do they have a bug open about this? I haven't checked, I don't even know where their bug reporting tool is.
unac_string() was corrupting memory by passing int* as size_t*, this only happens in 64bit platforms, I've committed a fix to mimic unac_string() (was converting to utf16, removing accents and converting back to utf8) in Tracker. Seeing how the most recent commit in unac is 6 years old, and the notorious lack of webpage or further information at all across the internet, looks like it's going to be close to impossible to get a fix in there... Closing as RESOLVED WORKAROUNDED :P