[LAD] [LAU] [LAA] Guitarix release 0.23.0

[hermann meyer]

Am 08.07.2012 07:10, schrieb hermann:
> Am Samstag, den 07.07.2012, 23:22 +0100 schrieb James Morris:
>> On 07/07/12 hermann <brummer- at web.de> wrote:
>>> Am Freitag, den 06.07.2012, 22:07 +0200 schrieb jeremy at autostatic.com:
>>>> Ran a backtrace, attached the output.
>>>>
>>>> Jeremy
>>> Hi Jeremy
>>>
>>> Thanks for the backtrace, unfortunately it isn't really meaningful, so
>>> I have installed ubuntu 12.04 on my box and build guitarix 0.23.1 on
>>> it. well, I cant reproduce the crash here, only conclusion that leaved
>>> over for me is that it is related to x86_64 because I have only i386.
>>>
>>> I will try to get access to a 64bit box to debug it, . . :-S
>>>
>> If it helps here's a backtrace on 64bit Arch, using plugin 4x4 pole
>> all pass:
>>
>>
>> Thread 2 (Thread 0x7f6854bcb700 (LWP 2503)):
>> #0  0x00007f6861d4be79 in do_sigwait () from /lib/libpthread.so.0
>> #1  0x00007f6861d4bf0b in sigwait () from /lib/libpthread.so.0
>> #2  0x0000000000625bfd in PosixSignals::signal_helper_thread() ()
>> #3  0x00007f685de268bd in ?? () from /usr/lib/libglibmm-2.4.so.1
>> #4  0x00007f6861443105 in ?? () from /usr/lib/libglib-2.0.so.0
>> #5  0x00007f6861d44e0e in start_thread () from /lib/libpthread.so.0
>> #6  0x00007f685c3561ed in clone () from /lib/libc.so.6
>>
>> Thread 1 (Thread 0x7f686255b8c0 (LWP 2502)):
>> #0  0x00007f685c2a6c35 in raise () from /lib/libc.so.6
>> #1  0x00007f685c2a80b8 in abort () from /lib/libc.so.6
>> #2  0x00007f685cb7dc6d in __gnu_cxx::__verbose_terminate_handler() ()
>> from /usr/lib/libstdc++.so.6 #3  0x00007f685cb7bd76 in ?? ()
>> from /usr/lib/libstdc++.so.6 #4  0x00007f685cb7bda3 in std::terminate()
>> () from /usr/lib/libstdc++.so.6 #5  0x00007f685cb7bfce in __cxa_throw
>> () from /usr/lib/libstdc++.so.6 #6  0x00007f685cbcef8d in
>> std::__throw_out_of_range(char const*) () from /usr/lib/libstdc++.so.6
>> #7  0x00007f685de34fa9 in Glib::ustring::erase(unsigned long, unsigned
>> long) () from /usr/lib/libglibmm-2.4.so.1 #8  0x00000000004d05ed in
>> gx_engine::LadspaDsp::registerparam(ParamReg const&) () #9
>> 0x000000000057a3d0 in
>> gx_engine::PluginList::registerParameter(gx_engine::Plugin*,
>> gx_engine::ParamMap&, gx_engine::ParamRegImpl&) () #10
>> 0x000000000057b292 in
>> gx_engine::PluginList::registerAllPlugins(gx_engine::ParamMap&,
>> gx_engine::ParameterGroups&) () #11 0x0000000000577cbd in
>> gx_engine::GxEngine::GxEngine(std::string const&, gx_engine::ParamMap&,
>> gx_engine::ParameterGroups&, gx_system::CmdlineOptions const&) () #12
>> 0x00000000004ce418 in main ()
>>
> Hi James
>
> Yes, that points me to our TrimLabel() function line 293
> in /src/gx_head/engine/ladspaplugin.cpp
>
> @@ -300,7 +300,11 @@
>   	pn.erase(rem);
>       }
>       while ((rem = pn.find_last_of(" ")) == pn.size()-1) {
> -	pn.erase(rem);
> +        if(rem != Glib::ustring::npos) {
> +        pn.erase(rem);
> +        } else {
> +        break;
> +        }
>       }
>       rem = 0;
>       unsigned int rem1 = 0;
>
> would be great if someone could check if that helps on a 64bit arch?
>
> greets
> hermann

After some research I come to the conclusion that the culprit is the use 
of unsigned int for the Glb::ustring::iterators.
replace all used unsigned int in function TrimLabel() with size_t 
instead the patch above should do the trick.

Unfortunately I haven´t access  to a 64bit machine,  so again cant test 
it, . .  .

greets
hermann