GNOME Bugzilla – Bug 672293
Trying to add a new language: crash while typing in the search field before the language list is completely populated
Last modified: 2012-03-27 11:54:23 UTC
To reproduce go to 'region and language' -> language -> + -> start typing in search input while the list is still being populated. Also crashes for 'region and language' -> format -> + -> start typing... control-center-3.3.91-1.fc17.x86_64 Also happening on Fedora 16, downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=752806 warning: core file may not match specified executable file. [New LWP 10344] [New LWP 10346] [New LWP 10347] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: "/var/cache/abrt-di/usr/lib/debug/usr/lib64/libicudata.so.48.1.1.debug": separate debug info file has no debug info Core was generated by `gnome-control-center --overview'. Program terminated with signal 11, Segmentation fault.
+ Trace 229900
Thread 1 (Thread 0x7f081082a980 (LWP 10344))
Created attachment 210080 [details] [review] possible patch Here is a patch that should fix this issue.
Looks good to me, Frank, can you retest with this patch applied please. Thanks.
(In reply to comment #2) > Looks good to me, Frank, can you retest with this patch applied please. Thanks. Sorry, I can't test the patch right now because parts of my jhbuild are broken, still searching for the cause.
Applied the patch on top of a7aa5f0c77277b9317cd77fbb832152920a9403e, working for me, no more crashes for both cases (language and format tab).
Created attachment 210688 [details] [review] common: Fix crash when filtering language list And it's still being populated. If the list gets filtered while it's being populated, we would end up with a row with NULL data, causing us to crash. Make sure to hold the GDK threads lock when reading from the list, to avoid racing with the insert code. http://bugzilla.gnome.org/show_bug.cgi?id=672293
Comment on attachment 210080 [details] [review] possible patch I've applied this patch as an optimisation. It wouldn't fix the bug, as the insertions are still done in the same way, without any locks held.