GNOME Bugzilla – Bug 340854
crash (segfault) when incremental searching past song titled "Never"
Last modified: 2006-05-06 21:53:47 UTC
Distribution: Debian testing/unstable Version: GNOME2.14.1 0.9.3 Gnome-Distributor: Debian BugBuddy-GnomeVersion: 2.0 (2.14.1) Description of the crash: segfault in type_ahead_search_func due to entry->title having never been folded. Steps to reproduce the crash: 1. Add a song whose title metadata is "Never" (exactly) to your library 2. In the library view, starting from the first song, try to incremental-search past the newly-added song (typing a number of 'z's works for me) 3. It will crash Expected Results: It should not crash :) How often does this happen? Every time (as long as you have such a song in your play list) Additional Information: I have not checked 0.9.4 yet. I notice 0.9.4 uses a different mechanism for accessing the folded value, but this bug could still exist. the problem can be traced to rb-refstring.c, rb_refstring_new_full: if you pass in a string that has been both (1) referenced before, and (2) matches an internal string, then you get an RBRefString whose folded value is NULL. The flow is basically: 1. "Never" gets _new_full()'ed internally early on, with compute_sortdata=FALSE thus, ret->folded and ret->sortkey = NULL. 2. "Never" gets used in a song name, with compute_sortdata=TRUE this function ignores compute_sortdata and returns the original "Never" string, with NULL folded and sortkey values. 3. Inc-search passes rb_refstring_get_folded(entry->title) to strstr. As you recall, title was never folded, so get_folded returns NULL, which violates strstr's interface. A crash (null pointer dereference) ensues. If I patch rb_refstring_new_full as follows, the crash goes away. if the string is found ('ret' test early on), and if compute_sortdata is true and the 'folded' property is null, then initialize folded and sortkey (since they weren't before) in the same was as is done a few lines down. Basically, the problem seems to be that "strings" have identity confusion: _new_full's algorithm implies the contents of the string (the char*) wholly identify the string. However, the actual contents of the RBRefString include meta-data that may be different for two "identical" strings (the meta-data are solely performance-enhancement-related, given the code I'm looking at in 0.9.3). An example of this case is "Never", which is used both in strings that won't be searched (like "time last played") and those that will (like "song title"). Other ways to solve it: * compute and add the metadata when it's accessed for the first time (since all accesses appear to be through functions, even in CVS HEAD). * raise an error (or warning) when metadata is accessed that was never set (doesn't actually fix it, but helps find other occurrences). * use some API that can gracefully accept NULL pointers in type_ahead_search_func (would cause another bug: song titles matching internal strings can't be searched for). See also: bug 330226 (modified the API used for getting this kind of meta-data; dated after the code in my backtrace) Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1495128384 (LWP 15244)] [New Thread -1512133712 (LWP 15246)] [New Thread -1503741008 (LWP 15245)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 68062
Thread 1 (Thread -1495128384 (LWP 15244))
The mechanism used in 0.9.4+ for creating folded and sort key forms of reference counted strings doesn't have this problem, as it creates the alternate forms the first time they are requested. *** This bug has been marked as a duplicate of 332992 ***