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 609850 - tracker-store segfault in tracker_parser_process_word
tracker-store segfault in tracker_parser_process_word
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Store
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: tracker-general
Jamie McCracken
Depends on:
Blocks:
 
 
Reported: 2010-02-13 17:34 UTC by freggy1
Modified: 2010-03-05 17:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description freggy1 2010-02-13 17:34:43 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.

Thread 1 (Thread 3635)

  • #0 tracker_parser_process_word
    at tracker-parser.c line 594
  • #1 parser_next
    at tracker-parser.c line 446
  • #2 tracker_parser_next
    at tracker-parser.c line 636
  • #3 buildTerms
    at tracker-fts.c line 4775
  • #4 tracker_data_resource_buffer_flush
    at tracker-data-update.c line 615
  • #5 tracker_data_update_buffer_flush
    at tracker-data-update.c line 647
  • #6 tracker_sparql_query_execute_insert_or_delete
    at tracker-sparql-query.c line 3313
  • #7 tracker_sparql_query_execute_insert
    at tracker-sparql-query.c line 3051
  • #8 tracker_sparql_query_execute_update
    at tracker-sparql-query.c line 1312
  • #9 tracker_data_update_sparql
    at tracker-data-update.c line 2161
  • #10 queue_idle_handler
    at tracker-store.c line 178
  • #11 g_main_dispatch
    at gmain.c line 1960
  • #12 IA__g_main_context_dispatch
    at gmain.c line 2513
  • #13 g_main_context_iterate
    at gmain.c line 2591
  • #14 IA__g_main_loop_run
    at gmain.c line 2799
  • #15 main
    at tracker-main.c line 482

Comment 1 Martyn Russell 2010-02-13 19:09:07 UTC
(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).
Comment 2 Philip Van Hoof 2010-03-03 11:03:18 UTC
(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?
Comment 3 Martyn Russell 2010-03-05 11:04:43 UTC
(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.
Comment 4 Carlos Garnacho 2010-03-05 17:25:57 UTC
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