I was trying to read the file info for an MP3. This is reproducible (I tried it thrice by the time I got the backtrace). <At this point, I scrolled past the file so it's time and title were picked up.> ** (xfmedia:933): WARNING **: Xfmedia: Unable to convert string to UTF-8 using default method (1): Invalid byte sequence in conversion input [New Thread 262149 (LWP 959)] ** (xfmedia:933): WARNING **: Xfmedia: Unable to convert string to UTF-8 using default method (1): Invalid byte sequence in conversion input (xfmedia:933): Gtk-WARNING **: Failed to set label from markup due to error parsing markup: Error on line 1 char 9: Invalid UTF-8 encoded text ** (xfmedia:933): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() ** (xfmedia:933): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() ** (xfmedia:933): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() <Here I tried to open the file info.> Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 933)] 0x40780169 in mallopt () from /lib/libc.so.6 (gdb) bt #0 0x40780169 in mallopt () from /lib/libc.so.6 #1 0x4077efe4 in free () from /lib/libc.so.6 #2 0x4048fc25 in g_free () from /usr/lib/libglib-2.0.so.0 #3 0x0827de10 in ?? () #4 0x0827dc98 in ?? () #5 0xbfffe9b0 in ?? () #6 0x0806c54f in xfmedia_playlist_file_info_cb ()
that crash has actually been fixed in CVS for a good week or so. FYI, the cause is *not* utf-8 errors. those warnings you're seeing are xfmedia doing the Right Thing, i.e., not allowing the use of strings where it can't properly convert them to utf-8. this shouldn't ever be a problem with xine-lib-1.0 final; i believe a patch just went in the other day to guarantee that all meta info functions always return valid utf-8. the odd part are the pango errors; looking at my code, there's absolutely no way that a non-utf-8 string could get to pango. well, unless the filename itself can't be converted to utf-8 either, maybe. if that's the case, i totally give up. anyway, the actual cause of your bug was due a math error that had me accessing invalid memory locations while converting numbers ("123456") into their 'pretty-print' equlvalent ("123,456").
Interesting background and side info; thanks for fixing! :)