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

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-@web.de> wrote:
>>> Am Freitag, den 06.07.2012, 22:07 +0200 schrieb jeremy@email-addr-hidden:
>>>> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Jul 8 12:15:01 2012