Crash on invalid string

[yunake]

Now that the plugin builds and works, I'd like to report the following crash:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

Thread 31 "deadbeef-main" received signal SIGABRT, Aborted.

(gdb) bt
#0  0x00007ffff734a04f in raise () from /usr/lib/libc.so.6
#1  0x00007ffff734b47a in abort () from /usr/lib/libc.so.6
#2  0x00007fffec59d4bd in __gnu_cxx::__verbose_terminate_handler () at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007fffec59b276 in __cxxabiv1::__terminate (handler=<optimized out>) at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x00007fffec59b2c1 in std::terminate () at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x00007fffec59b4d8 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x7fff900015a0, tinfo=0x7fffec886a38 <typeinfo for std::logic_error>, 
    dest=0x7fffec5b0cc0 <std::logic_error::~logic_error()>) at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007fffec5c4caf in std::__throw_logic_error (__s=0x7fffee5921d8 "basic_string::_M_construct null not valid")
    at /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/functexcept.cc:74
#7  0x00007fffee58ee13 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.41] () from /home/yunake/.local/lib64/deadbeef/ddb_lyricbar_gtk2.so
#8  0x00007fffee5905f2 in update_lyrics(void*) () from /home/yunake/.local/lib64/deadbeef/ddb_lyricbar_gtk2.so
#9  0x00007ffff76bc454 in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007ffff73ff7df in clone () from /usr/lib/libc.so.6

No IO at that moment, and no lyrics cache for the song. I don't even need to play this song, just selecting it in the playlist is enough to trigger this crash.

This only happens with one particular file. Would you like me to share the file with you? Something is seriously wrong with it, no tool can read its tag. I've tried using my trusty eyeD3 to remove all tags — still crashes; i've forcefully added an empty v1.1 and v2.4 tags — still crashes.

Because this is such a weird situation that is probably not widespread at all, and it feels okay to assume pl_find_meta() only returns "safe" strings, it might be viable to just ignore this altogether. I just thought I'll share this with you anyway.

[yunake]

hmm, after some more debugging it seems like pl_find_meta returns simply NULL in this case.

(gdb) list
159             title  = deadbeef->pl_find_meta(track, "title");
160             cerr<<artist<<endl;
161             cerr<<title<<endl;
162         }
(gdb) info locals
lyrics = std::experimental::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >> [no contained value]
track = 0x555555e51080
artist = 0x0
title = 0x0
(gdb) print deadbeef->pl_find_meta(track, "title")
$4 = 0x0
(gdb) print deadbeef->pl_find_meta(track, "artist")
$11 = 0x0

[yunake]

i've tried applying a similar fix myself with no luck. anyways, i did a clean checkout of master with all your changes, and was able to compile applying my changes to the Makefile again.

deadbeef still crashes, but with a different backtrace, it seems some weird string is being pushed through the UI thread, causing strlen() to fail down the line:

Thread 1 "deadbeef-gtkui" received signal SIGSEGV, Segmentation fault.
0x00007ffff7397446 in strlen () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7397446 in strlen () from /usr/lib/libc.so.6
#1  0x00007fffecd206e4 in Glib::ustring::operator=(char const*) () from /usr/lib/libglibmm-2.4.so.1
#2  0x00007fffee58e008 in <lambda()>::operator()(void) const (__closure=0x7fffa4001210) at ui.cpp:35
#3  0x00007fffecd18d80 in ?? () from /usr/lib/libglibmm-2.4.so.1
#4  0x00007ffff499cd1a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#5  0x00007ffff499d0d0 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0x00007ffff499d3f2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#7  0x00007ffff6b07347 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#8  0x00007ffff70759cf in gtkui_thread () from /usr/lib/deadbeef/ddb_gui_GTK2.so
#9  0x00007ffff7075c31 in ?? () from /usr/lib/deadbeef/ddb_gui_GTK2.so
#10 0x00005555555880fe in ?? ()
#11 0x00007ffff7337291 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x000055555558835a in ?? ()

I've also verified that the song plays correctly if i remove the plugin so, just in case.

[loskutov]

Oops, I forgot to fix the Makefile. Anyway, now it seems to work.

[yunake]

hey yesss! it bloody works now :)

i need the gkt2.4->2.0 change too but it could just be some new flavour of Arch weirdness, whaddaya know :)

thank you so much Игнат!

[loskutov]

I guess it's again me, developing on a machine with gtk3 only and copy-pasting gtkmm to gtk :smile:. That's right, it's gtkmm-2.4 but gtk-2.0. Fixed.