Crash on state restore

[x42]

I guess a debug build of BHarvestr.so would be needed to narrow this down and determine if it indeed this plugin (and not the host or liblilv) that it to blame for. Unless the state.ttl file provides you with sufficient information.

0x00007fffed019d56 in std::char_traits<char>::find (__a=@0x1a0310c6c7800000: <error reading variable>, __n=684, __s=0x5555e4f0b260 ";\nshp:4; typ:0; ptx:1.000000; pty:0.000000; h1x:0.000000; h1y:0.000000; h2x:0.000000; h2y:0.000000;\nshp:5; typ:0; ptx:0.000000; pty:0.000000; h1x:0.000000; h1y:0.000000; h2x:0.000000; h2y:0.000000;\nsh"...) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:371
371     /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h: No such file or directory.
(gdb) bt
#0  0x00007fffed019d56 in std::char_traits<char>::find (__a=@0x1a0310c6c7800000: <error reading variable>, __n=684,
    __s=0x5555e4f0b260 ";\nshp:4; typ:0; ptx:1.000000; pty:0.000000; h1x:0.000000; h1y:0.000000; h2x:0.000000; h2y:0.000000;\nshp:5; typ:0; ptx:0.000000; pty:0.000000; h1x:0.000000; h1y:0.000000; h2x:0.000000; h2y:0.000000;\nsh"...)
    at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:371
#1  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find (this=<optimized out>, __s=0x1a0310c6c7800000 <error: Cannot access memory at address 0x1a0310c6c7800000>, __pos=<optimized out>, __n=5)
    at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1219
#2  0x00007fff540b4ee2 in ?? () from /usr/lib/lv2/BHarvestr.lv2/BHarvestr.so
#3  0x00007fffee7be234 in lilv_state_restore () from /opt/Ardour-6.6.56-dbg/lib/liblilv-0.so.0
#4  0x00007ffff724f7c1 in ARDOUR::LV2Plugin::set_state (this=0x5555e4d79700, node=..., version=6000) at ../libs/ardour/lv2_plugin.cc:2243

https://mantis.ardour.org/view.php?id=8588 state files: https://mantis.ardour.org/file_download.php?file_id=3955&type=bug

-- PS. When saving floats as string, beware of localization issues "1,0" vs "1.0". Why not just use save it as LV2_ATOM__Vector or LV2_ATOM__Float?

[sjaehn]

Thanks for info. I made some commits in save & restore in the meantime. But I don't think that they will fix this issue (unless it's caused by a freed nullptr returned from abstract_path()). @unfa may I ask you to compile B.Harvestr with make CPPFLAGS+=-g (I know it isn't a CPPFLAG but this is the easiest way). Then I will know where exactly this crash is caused. In the meantime I'll build ardour 6.6. Maybe I can reproduce it.

@x42 I know saving the pattern and shape values as a string is ugly (with respect to the lv2 specs). And not really necessary here (at least this simple pattern as a LV2_ATOM_Vector would be fine). However it may provide a more efficient for a large amount of data (like large vectors of objects with different kinds of values as in B.SEQuenzr). And I take care about localization. Although floats are localization-dependently stored as strings using snprintf(). But the restore() method uses my own stof() that handles both, decimal point and decimal comma.

[sjaehn]

I made some experiments with ardour 6.6 yesterday. And yes there are crashes on loading: free(): invalid pointer.

But all of them occur if I open a project created with a previous version of ardour for the first time with ardour 6.6. It happens in at least 80% of projects created with ardour before 6.6 (I had some cases without crash, but I'm not sure if I tried to open them before). Crashes happen in all of the following scenarios, if I load projects with B.Harvestr, if I load projects with other B.Music plugins, or even if I load plugins without any B.Music plugins. But there are absolutely no crashes if I try to Ioad the respective project for the second time.

I'm not sure if my observations are related to the bug reported by @unfa. If not, may I ask you to send me the ardour project files.

[x42]

Very likely this is caused memory corruption (which would also explain why v6.5 and v6.6. behave differently).
free(): invalid pointer supports that hypothesis.

Running the plugins in valgrind may or may not shed some light.