Hi Andres,

Thanks for following up on that.  Yes, I think we need to ensure that
these are not going to crash on multiple renders.  Do you or anyone
else have time to write a quick .c program that will render a csd
multiple times so that we can reproduce the crash and trace with GDB
easily?  (I need to look at other things for the next bit of my work
time, but can help debug/test later)

Thanks!
steven

On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Hi Steven,
>
> It was solved for me by removing libLuaOpcodes... :P
> BTW, I'm having a similar issue with libsignalflow opcodes, so I've had to
> take those out as well. They seem not to be cleaning up correctly. I think
> it's important to fix these before release or not include them in installers
> as they will crash all hosts that do more than one run.
>
> Cheers,
> Andrés
>
>
> On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> Hi All,
>>
>> I've taken a look at the changes from Michael. For Android, to get
>> things working to use downloadDependencies.sh and build-all.sh, I made
>> the following modifications:
>>
>> 1. I updated the fluidsynth-android Bitbucket repository with the
>> Application.mk and Android.mk that MIchael recently committed, and
>> consequently removed the ones from Csound6's git repo.  This means the
>> repo for fluidsynth-android will have the most up to date files.
>>
>> 2. I moved luajit-2.0 from plugins to plugins/patches.
>> downloadDependencies.sh now copies over the jni folder from
>> plugins/patches/luajit-2.0 to the place where it checked out from GIT
>> for luajit.
>>
>>
>> I did some further testing about plugins and I think at this point,
>> the crashing problem on my device is not with loading of libs but
>> specifically the Lua opcodes.  If I remove just that library, I can
>> load/reload/render multiple times without crashes.  I believe Andres
>> had posted an issue where the Lua opcodes was crashing on load for his
>> system but that seems to be resolved for him.  I haven't found a good
>> way to debug this on Android (I haven't gotten ndk-gdb to connect).
>>
>> Thanks!
>> steven
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I just ran the testCsoundTypeSystem here, it appears to pass alright:

coltrane:c victor$ ./testCsoundTypeSystem 

     CUnit - A unit testing framework for C - Version 2.1-2

     http://cunit.sourceforge.net/

Suite: Type System Tests

  Test: Test Type System ...virtual_keyboard real time MIDI plugin for Csound

0dBFS level = 32768.0

Csound version 6.00 (double samples) Jul  4 2013

libsndfile-1.0.21

passed

  Test: Test getVarSimpleName ...virtual_keyboard real time MIDI plugin for Csound

0dBFS level = 32768.0

Csound version 6.00 (double samples) Jul  4 2013

libsndfile-1.0.21

passed

Run Summary:    Type  Total    Ran Passed Failed Inactive

              suites      1      1    n/a      0        0

               tests      2      2      2      0        0

             asserts      9      9      9      0      n/a

Elapsed time =    0.061 seconds

end of score.   overall amps:      0.0

  overall samples out of range:        0

0 errors in performance

Elapsed time at end of performance: real: 0.251s, CPU: 0.001s

end of score.   overall amps:      0.0

  overall samples out of range:        0

0 errors in performance

Elapsed time at end of performance: real: 0.316s, CPU: 0.020s

On 5 Jul 2013, at 21:58, Andres Cabrera wrote:

You can use the test programs to check:
testChannels will run fine, but testCsoundTypeSystem will fail.

Cheers,
Andrés

On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Andres,

Thanks for following up on that.  Yes, I think we need to ensure that
these are not going to crash on multiple renders.  Do you or anyone
else have time to write a quick .c program that will render a csd
multiple times so that we can reproduce the crash and trace with GDB
easily?  (I need to look at other things for the next bit of my work
time, but can help debug/test later)

Thanks!
steven

On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Hi Steven,
>
> It was solved for me by removing libLuaOpcodes... :P
> BTW, I'm having a similar issue with libsignalflow opcodes, so I've had to
> take those out as well. They seem not to be cleaning up correctly. I think
> it's important to fix these before release or not include them in installers
> as they will crash all hosts that do more than one run.
>
> Cheers,
> Andrés
>
>
> On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> Hi All,
>>
>> I've taken a look at the changes from Michael. For Android, to get
>> things working to use downloadDependencies.sh and build-all.sh, I made
>> the following modifications:
>>
>> 1. I updated the fluidsynth-android Bitbucket repository with the
>> Application.mk and Android.mk that MIchael recently committed, and
>> consequently removed the ones from Csound6's git repo.  This means the
>> repo for fluidsynth-android will have the most up to date files.
>>
>> 2. I moved luajit-2.0 from plugins to plugins/patches.
>> downloadDependencies.sh now copies over the jni folder from
>> plugins/patches/luajit-2.0 to the place where it checked out from GIT
>> for luajit.
>>
>>
>> I did some further testing about plugins and I think at this point,
>> the crashing problem on my device is not with loading of libs but
>> specifically the Lua opcodes.  If I remove just that library, I can
>> load/reload/render multiple times without crashes.  I believe Andres
>> had posted an issue where the Lua opcodes was crashing on load for his
>> system but that seems to be resolved for him.  I haven't found a good
>> way to debug this on Android (I haven't gotten ndk-gdb to connect).
>>
>> Thanks!
>> steven
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Just some follow up, I had put a breakpoint on manageLuaState. Using
testCsoundOrcSemantics, I saw five calls with "O" during the tests,
then ctest printed its report, then with the call to manageLuaState
with "C", I get the crash with the call to erase.

I'm not used to debugging C++, but what I'm seeing is that the
iterator it during the "O" calls is:

{_M_current = 0x6f3370}

but on the "C" call I see:

{_M_current = 0x6f3380}

which is equal to the luaStatesForThreads.end().

So... I'm not sure what's going on.  Perhaps Michael could help
debug/test.  I also don't know if this is the cause of the issue on
Android as I haven't been able to really get gdb going there.

On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com> wrote:
> I ran "make test" on a Debian system and I get 3 failures.  CTest
> reports 2 of them are failed tests and one is a segfault. I ran the
> failed tests with gdb and got:
>
> with testCsoundTypeSystem:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>     __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400bf9 in _start ()
>
>
> with testCsoundOrcSemantics:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>     __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400c39 in _start ()
>
>
> with testCircularBuffer:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> 67        int itemsread, numelem = ((circular_buffer *)p)->numelem;
> (gdb) bt
> #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> #1  0x0000000000400fca in test_read_write_diff_size ()
>     at /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
> #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
> #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
> #4  0x00007ffff76bb6e8 in CU_run_all_tests () from /usr/lib/libcunit.so.1
> #5  0x0000000000401673 in main () at
> /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>
> On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
>> But then you don't have the Lua opcodes...
>>
>> I'll look again at the signal flow opcodes to see if it's a problem on my
>> end.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
>> wrote:
>>>
>>> I just ran the testCsoundTypeSystem here, it appears to pass alright:
>>>
>>> coltrane:c victor$ ./testCsoundTypeSystem
>>>
>>>
>>>      CUnit - A unit testing framework for C - Version 2.1-2
>>>      http://cunit.sourceforge.net/
>>>
>>>
>>> Suite: Type System Tests
>>>   Test: Test Type System ...virtual_keyboard real time MIDI plugin for
>>> Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>   Test: Test getVarSimpleName ...virtual_keyboard real time MIDI plugin
>>> for Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>
>>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>>>               suites      1      1    n/a      0        0
>>>                tests      2      2      2      0        0
>>>              asserts      9      9      9      0      n/a
>>>
>>> Elapsed time =    0.061 seconds
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.251s, CPU: 0.001s
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.316s, CPU: 0.020s
>>>
>>>
>>>
>>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>>>
>>> You can use the test programs to check:
>>> testChannels will run fine, but testCsoundTypeSystem will fail.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> Hi Andres,
>>>>
>>>> Thanks for following up on that.  Yes, I think we need to ensure that
>>>> these are not going to crash on multiple renders.  Do you or anyone
>>>> else have time to write a quick .c program that will render a csd
>>>> multiple times so that we can reproduce the crash and trace with GDB
>>>> easily?  (I need to look at other things for the next bit of my work
>>>> time, but can help debug/test later)
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera <mantaraya36@gmail.com>
>>>> wrote:
>>>> > Hi Steven,
>>>> >
>>>> > It was solved for me by removing libLuaOpcodes... :P
>>>> > BTW, I'm having a similar issue with libsignalflow opcodes, so I've had
>>>> > to
>>>> > take those out as well. They seem not to be cleaning up correctly. I
>>>> > think
>>>> > it's important to fix these before release or not include them in
>>>> > installers
>>>> > as they will crash all hosts that do more than one run.
>>>> >
>>>> > Cheers,
>>>> > Andrés
>>>> >
>>>> >
>>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> I've taken a look at the changes from Michael. For Android, to get
>>>> >> things working to use downloadDependencies.sh and build-all.sh, I made
>>>> >> the following modifications:
>>>> >>
>>>> >> 1. I updated the fluidsynth-android Bitbucket repository with the
>>>> >> Application.mk and Android.mk that MIchael recently committed, and
>>>> >> consequently removed the ones from Csound6's git repo.  This means the
>>>> >> repo for fluidsynth-android will have the most up to date files.
>>>> >>
>>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>>>> >> downloadDependencies.sh now copies over the jni folder from
>>>> >> plugins/patches/luajit-2.0 to the place where it checked out from GIT
>>>> >> for luajit.
>>>> >>
>>>> >>
>>>> >> I did some further testing about plugins and I think at this point,
>>>> >> the crashing problem on my device is not with loading of libs but
>>>> >> specifically the Lua opcodes.  If I remove just that library, I can
>>>> >> load/reload/render multiple times without crashes.  I believe Andres
>>>> >> had posted an issue where the Lua opcodes was crashing on load for his
>>>> >> system but that seems to be resolved for him.  I haven't found a good
>>>> >> way to debug this on Android (I haven't gotten ndk-gdb to connect).
>>>> >>
>>>> >> Thanks!
>>>> >> steven
>>>> >>
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> This SF.net email is sponsored by Windows:
>>>> >>
>>>> >> Build for Windows Store.
>>>> >>
>>>> >> http://p.sf.net/sfu/windows-dev2dev
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > This SF.net email is sponsored by Windows:
>>>> >
>>>> > Build for Windows Store.
>>>> >
>>>> > http://p.sf.net/sfu/windows-dev2dev
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Windows:
>>>>
>>>> Build for Windows Store.
>>>>
>>>> http://p.sf.net/sfu/windows-dev2dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>>
>>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Yes, these are the issues I'm having. I think they don't occur on windows because there is no function registered with atexit (see csoundInitialize), but I'm not sure why it's not crashing on Os X.

Cheers,
Andres

On Jul 5, 2013 7:03 PM, "Michael Gogins" <michael.gogins@gmail.com> wrote:

I'm happy to help, the information supplied will be helpful. Unfortunately, I don't get this crash here... but I can probably figure out what is going on. The module cleanup function is probably not being called. I'll see if there's a workaround or if it is being called at an inopportune time, or I'll just preallocate a fixed number of Lua states (one per Csound thread) and keep them around. Something.

Regards,

Mike

===========================

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com> wrote:

Just some follow up, I had put a breakpoint on manageLuaState. Using
testCsoundOrcSemantics, I saw five calls with "O" during the tests,
then ctest printed its report, then with the call to manageLuaState
with "C", I get the crash with the call to erase.

I'm not used to debugging C++, but what I'm seeing is that the
iterator it during the "O" calls is:

{_M_current = 0x6f3370}

but on the "C" call I see:

{_M_current = 0x6f3380}

which is equal to the luaStatesForThreads.end().

So... I'm not sure what's going on.  Perhaps Michael could help
debug/test.  I also don't know if this is the cause of the issue on
Android as I haven't been able to really get gdb going there.

On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com> wrote:
> I ran "make test" on a Debian system and I get 3 failures.  CTest
> reports 2 of them are failed tests and one is a segfault. I ran the
> failed tests with gdb and got:
>
> with testCsoundTypeSystem:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>     __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400bf9 in _start ()
>
>
> with testCsoundOrcSemantics:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>     __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400c39 in _start ()
>
>
> with testCircularBuffer:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> 67        int itemsread, numelem = ((circular_buffer *)p)->numelem;
> (gdb) bt
> #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> #1  0x0000000000400fca in test_read_write_diff_size ()
>     at /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
> #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
> #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
> #4  0x00007ffff76bb6e8 in CU_run_all_tests () from /usr/lib/libcunit.so.1
> #5  0x0000000000401673 in main () at
> /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>
> On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
>> But then you don't have the Lua opcodes...
>>
>> I'll look again at the signal flow opcodes to see if it's a problem on my
>> end.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
>> wrote:
>>>
>>> I just ran the testCsoundTypeSystem here, it appears to pass alright:
>>>
>>> coltrane:c victor$ ./testCsoundTypeSystem
>>>
>>>
>>>      CUnit - A unit testing framework for C - Version 2.1-2
>>>      http://cunit.sourceforge.net/
>>>
>>>
>>> Suite: Type System Tests
>>>   Test: Test Type System ...virtual_keyboard real time MIDI plugin for
>>> Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>   Test: Test getVarSimpleName ...virtual_keyboard real time MIDI plugin
>>> for Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>
>>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>>>               suites      1      1    n/a      0        0
>>>                tests      2      2      2      0        0
>>>              asserts      9      9      9      0      n/a
>>>
>>> Elapsed time =    0.061 seconds
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.251s, CPU: 0.001s
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.316s, CPU: 0.020s
>>>
>>>
>>>
>>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>>>
>>> You can use the test programs to check:
>>> testChannels will run fine, but testCsoundTypeSystem will fail.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> Hi Andres,
>>>>
>>>> Thanks for following up on that.  Yes, I think we need to ensure that
>>>> these are not going to crash on multiple renders.  Do you or anyone
>>>> else have time to write a quick .c program that will render a csd
>>>> multiple times so that we can reproduce the crash and trace with GDB
>>>> easily?  (I need to look at other things for the next bit of my work
>>>> time, but can help debug/test later)
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera <mantaraya36@gmail.com>
>>>> wrote:
>>>> > Hi Steven,
>>>> >
>>>> > It was solved for me by removing libLuaOpcodes... :P
>>>> > BTW, I'm having a similar issue with libsignalflow opcodes, so I've had
>>>> > to
>>>> > take those out as well. They seem not to be cleaning up correctly. I
>>>> > think
>>>> > it's important to fix these before release or not include them in
>>>> > installers
>>>> > as they will crash all hosts that do more than one run.
>>>> >
>>>> > Cheers,
>>>> > Andrés
>>>> >
>>>> >
>>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> I've taken a look at the changes from Michael. For Android, to get
>>>> >> things working to use downloadDependencies.sh and build-all.sh, I made
>>>> >> the following modifications:
>>>> >>
>>>> >> 1. I updated the fluidsynth-android Bitbucket repository with the
>>>> >> Application.mk and Android.mk that MIchael recently committed, and
>>>> >> consequently removed the ones from Csound6's git repo.  This means the
>>>> >> repo for fluidsynth-android will have the most up to date files.
>>>> >>
>>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>>>> >> downloadDependencies.sh now copies over the jni folder from
>>>> >> plugins/patches/luajit-2.0 to the place where it checked out from GIT
>>>> >> for luajit.
>>>> >>
>>>> >>
>>>> >> I did some further testing about plugins and I think at this point,
>>>> >> the crashing problem on my device is not with loading of libs but
>>>> >> specifically the Lua opcodes.  If I remove just that library, I can
>>>> >> load/reload/render multiple times without crashes.  I believe Andres
>>>> >> had posted an issue where the Lua opcodes was crashing on load for his
>>>> >> system but that seems to be resolved for him.  I haven't found a good
>>>> >> way to debug this on Android (I haven't gotten ndk-gdb to connect).
>>>> >>
>>>> >> Thanks!
>>>> >> steven
>>>> >>
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> This SF.net email is sponsored by Windows:
>>>> >>
>>>> >> Build for Windows Store.
>>>> >>
>>>> >> http://p.sf.net/sfu/windows-dev2dev
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > This SF.net email is sponsored by Windows:
>>>> >
>>>> > Build for Windows Store.
>>>> >
>>>> > http://p.sf.net/sfu/windows-dev2dev
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Windows:
>>>>
>>>> Build for Windows Store.
>>>>
>>>> http://p.sf.net/sfu/windows-dev2dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>>
>>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I changed the code some time ago so that this atexit stuff would not be called on WIndows, because it always caused a crash on exit and I had no idea how to fix it.

On Android, the NDK docs advise allowing Android itself to do all cleanup on exit, so I will change the CsoundAndroid  or CSDPlayuer code, whichever is most appropraite, to pass the CSOUNDINIT_NO_ATEXIT flag to csoundInitialize. Or something to avoid the atexit stuff on Android.

I don't know why I don't see this bug on the Galaxy S4.

Regards,

Mike

===========================

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Sat, Jul 6, 2013 at 10:49 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:

Yes, these are the issues I'm having. I think they don't occur on windows because there is no function registered with atexit (see csoundInitialize), but I'm not sure why it's not crashing on Os X.

Cheers,
Andres

On Jul 5, 2013 7:03 PM, "Michael Gogins" <michael.gogins@gmail.com> wrote:

I'm happy to help, the information supplied will be helpful. Unfortunately, I don't get this crash here... but I can probably figure out what is going on. The module cleanup function is probably not being called. I'll see if there's a workaround or if it is being called at an inopportune time, or I'll just preallocate a fixed number of Lua states (one per Csound thread) and keep them around. Something.

Regards,

Mike

===========================

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com> wrote:

Just some follow up, I had put a breakpoint on manageLuaState. Using
testCsoundOrcSemantics, I saw five calls with "O" during the tests,
then ctest printed its report, then with the call to manageLuaState
with "C", I get the crash with the call to erase.

I'm not used to debugging C++, but what I'm seeing is that the
iterator it during the "O" calls is:

{_M_current = 0x6f3370}

but on the "C" call I see:

{_M_current = 0x6f3380}

which is equal to the luaStatesForThreads.end().

So... I'm not sure what's going on.  Perhaps Michael could help
debug/test.  I also don't know if this is the cause of the issue on
Android as I haven't been able to really get gdb going there.

On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com> wrote:
> I ran "make test" on a Debian system and I get 3 failures.  CTest
> reports 2 of them are failed tests and one is a segfault. I ran the
> failed tests with gdb and got:
>
> with testCsoundTypeSystem:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>     __last=0x6f01e0, __result=0x6f01e0) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400bf9 in _start ()
>
>
> with testCsoundOrcSemantics:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff52b2286 in std::__copy_move<false, true,
> std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:366
> #2  0x00007ffff52b199e in std::__copy_move_a<false,
> LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>     __last=0x6f3380, __result=0x6f3380) at
> /usr/include/c++/4.7/bits/stl_algobase.h:384
> #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...)
>     at /usr/include/c++/4.7/bits/stl_algobase.h:422
> #4  0x00007ffff52af4af in
> std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
> __gnu_cxx::__normal_iterator<LuaStateForThread*,
> std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > > >
> (__first=..., __last=..., __result=...) at
> /usr/include/c++/4.7/bits/stl_algobase.h:454
> #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
> std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
> #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
> #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
> #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csmodule.c:637
> #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:2616
> #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
> /home/steven/csound/csound6/Top/csound.c:1190
> #11 0x00007ffff7a67747 in destroy_all_instances () at
> /home/steven/csound/csound6/Top/csound.c:888
> #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x00007ffff6f3ae45 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #14 0x00007ffff6f22eb4 in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #15 0x0000000000400c39 in _start ()
>
>
> with testCircularBuffer:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> 67        int itemsread, numelem = ((circular_buffer *)p)->numelem;
> (gdb) bt
> #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
> (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>     items=16) at /home/steven/csound/csound6/InOut/circularbuffer.c:67
> #1  0x0000000000400fca in test_read_write_diff_size ()
>     at /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
> #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
> #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
> #4  0x00007ffff76bb6e8 in CU_run_all_tests () from /usr/lib/libcunit.so.1
> #5  0x0000000000401673 in main () at
> /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>
> On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
>> But then you don't have the Lua opcodes...
>>
>> I'll look again at the signal flow opcodes to see if it's a problem on my
>> end.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
>> wrote:
>>>
>>> I just ran the testCsoundTypeSystem here, it appears to pass alright:
>>>
>>> coltrane:c victor$ ./testCsoundTypeSystem
>>>
>>>
>>>      CUnit - A unit testing framework for C - Version 2.1-2
>>>      http://cunit.sourceforge.net/
>>>
>>>
>>> Suite: Type System Tests
>>>   Test: Test Type System ...virtual_keyboard real time MIDI plugin for
>>> Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>   Test: Test getVarSimpleName ...virtual_keyboard real time MIDI plugin
>>> for Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.00 (double samples) Jul  4 2013
>>> libsndfile-1.0.21
>>> passed
>>>
>>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>>>               suites      1      1    n/a      0        0
>>>                tests      2      2      2      0        0
>>>              asserts      9      9      9      0      n/a
>>>
>>> Elapsed time =    0.061 seconds
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.251s, CPU: 0.001s
>>> end of score.   overall amps:      0.0
>>>   overall samples out of range:        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.316s, CPU: 0.020s
>>>
>>>
>>>
>>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>>>
>>> You can use the test programs to check:
>>> testChannels will run fine, but testCsoundTypeSystem will fail.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> Hi Andres,
>>>>
>>>> Thanks for following up on that.  Yes, I think we need to ensure that
>>>> these are not going to crash on multiple renders.  Do you or anyone
>>>> else have time to write a quick .c program that will render a csd
>>>> multiple times so that we can reproduce the crash and trace with GDB
>>>> easily?  (I need to look at other things for the next bit of my work
>>>> time, but can help debug/test later)
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera <mantaraya36@gmail.com>
>>>> wrote:
>>>> > Hi Steven,
>>>> >
>>>> > It was solved for me by removing libLuaOpcodes... :P
>>>> > BTW, I'm having a similar issue with libsignalflow opcodes, so I've had
>>>> > to
>>>> > take those out as well. They seem not to be cleaning up correctly. I
>>>> > think
>>>> > it's important to fix these before release or not include them in
>>>> > installers
>>>> > as they will crash all hosts that do more than one run.
>>>> >
>>>> > Cheers,
>>>> > Andrés
>>>> >
>>>> >
>>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> I've taken a look at the changes from Michael. For Android, to get
>>>> >> things working to use downloadDependencies.sh and build-all.sh, I made
>>>> >> the following modifications:
>>>> >>
>>>> >> 1. I updated the fluidsynth-android Bitbucket repository with the
>>>> >> Application.mk and Android.mk that MIchael recently committed, and
>>>> >> consequently removed the ones from Csound6's git repo.  This means the
>>>> >> repo for fluidsynth-android will have the most up to date files.
>>>> >>
>>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>>>> >> downloadDependencies.sh now copies over the jni folder from
>>>> >> plugins/patches/luajit-2.0 to the place where it checked out from GIT
>>>> >> for luajit.
>>>> >>
>>>> >>
>>>> >> I did some further testing about plugins and I think at this point,
>>>> >> the crashing problem on my device is not with loading of libs but
>>>> >> specifically the Lua opcodes.  If I remove just that library, I can
>>>> >> load/reload/render multiple times without crashes.  I believe Andres
>>>> >> had posted an issue where the Lua opcodes was crashing on load for his
>>>> >> system but that seems to be resolved for him.  I haven't found a good
>>>> >> way to debug this on Android (I haven't gotten ndk-gdb to connect).
>>>> >>
>>>> >> Thanks!
>>>> >> steven
>>>> >>
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> This SF.net email is sponsored by Windows:
>>>> >>
>>>> >> Build for Windows Store.
>>>> >>
>>>> >> http://p.sf.net/sfu/windows-dev2dev
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > This SF.net email is sponsored by Windows:
>>>> >
>>>> > Build for Windows Store.
>>>> >
>>>> > http://p.sf.net/sfu/windows-dev2dev
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Windows:
>>>>
>>>> Build for Windows Store.
>>>>
>>>> http://p.sf.net/sfu/windows-dev2dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>>
>>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Michael,

I just tried CSDPlayer and it's still crashing.  I imagine Linux will
still crash since this change doesn't apply for it there.

I wonder if there's some weird issue with how static is treated on
*nix with gcc (which would apply to Linux and Android both). Seems
like a longshot but I'm really not sure what's going on. :)   I'm
catching up a bit today on things before heading back to unpacking,
but will try to do some further gdb diagnosis on Linux.

Thanks!
steven

On Sat, Jul 6, 2013 at 12:24 PM, Michael Gogins

<michael.gogins@gmail.com> wrote:
> I have pushed code to call csoundInitialize(CSOUNDINIT_NO_ATEXIT) in
> CSDPlayer's static initialization block. As I understand it, this function
> only needs to be called once in process, is that correct?
>
> By the way, Steven, thanks for doing the patches directory.
>
> Regards,
> Mike
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sat, Jul 6, 2013 at 11:44 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I changed the code some time ago so that this atexit stuff would not be
>> called on WIndows, because it always caused a crash on exit and I had no
>> idea how to fix it.
>>
>> On Android, the NDK docs advise allowing Android itself to do all cleanup
>> on exit, so I will change the CsoundAndroid  or CSDPlayuer code, whichever
>> is most appropraite, to pass the CSOUNDINIT_NO_ATEXIT flag to
>> csoundInitialize. Or something to avoid the atexit stuff on Android.
>>
>> I don't know why I don't see this bug on the Galaxy S4.
>>
>> Regards,
>> Mike
>>
>>
>> ===========================
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sat, Jul 6, 2013 at 10:49 AM, Andres Cabrera <mantaraya36@gmail.com>
>> wrote:
>>>
>>> Yes, these are the issues I'm having. I think they don't occur on windows
>>> because there is no function registered with atexit (see csoundInitialize),
>>> but I'm not sure why it's not crashing on Os X.
>>>
>>> Cheers,
>>> Andres
>>>
>>> On Jul 5, 2013 7:03 PM, "Michael Gogins" <michael.gogins@gmail.com>
>>> wrote:
>>>>
>>>> I'm happy to help, the information supplied will be helpful.
>>>> Unfortunately, I don't get this crash here... but I can probably figure out
>>>> what is going on. The module cleanup function is probably not being called.
>>>> I'll see if there's a workaround or if it is being called at an inopportune
>>>> time, or I'll just preallocate a fixed number of Lua states (one per Csound
>>>> thread) and keep them around. Something.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>> ===========================
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>
>>>>> Just some follow up, I had put a breakpoint on manageLuaState. Using
>>>>> testCsoundOrcSemantics, I saw five calls with "O" during the tests,
>>>>> then ctest printed its report, then with the call to manageLuaState
>>>>> with "C", I get the crash with the call to erase.
>>>>>
>>>>> I'm not used to debugging C++, but what I'm seeing is that the
>>>>> iterator it during the "O" calls is:
>>>>>
>>>>> {_M_current = 0x6f3370}
>>>>>
>>>>> but on the "C" call I see:
>>>>>
>>>>> {_M_current = 0x6f3380}
>>>>>
>>>>> which is equal to the luaStatesForThreads.end().
>>>>>
>>>>> So... I'm not sure what's going on.  Perhaps Michael could help
>>>>> debug/test.  I also don't know if this is the cause of the issue on
>>>>> Android as I haven't been able to really get gdb going there.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>> > I ran "make test" on a Debian system and I get 3 failures.  CTest
>>>>> > reports 2 of them are failed tests and one is a segfault. I ran the
>>>>> > failed tests with gdb and got:
>>>>> >
>>>>> > with testCsoundTypeSystem:
>>>>> >
>>>>> > Program received signal SIGSEGV, Segmentation fault.
>>>>> > 0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > (gdb) bt
>>>>> > #0  0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>>>>> >     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>>>>> >     __last=0x6f01e0, __result=0x6f01e0) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >
>>>>> > >
>>>>> > (__first=..., __last=..., __result=...)
>>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>>>>> > #4  0x00007ffff52af4af in
>>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >
>>>>> > >
>>>>> > (__first=..., __last=..., __result=...) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>>>>> > std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>>>>> >     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
>>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x6fa860) at
>>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x6fa860) at
>>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
>>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
>>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>>>>> > /home/steven/csound/csound6/Top/csound.c:888
>>>>> > #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #13 0x00007ffff6f3ae45 in exit () from
>>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #15 0x0000000000400bf9 in _start ()
>>>>> >
>>>>> >
>>>>> > with testCsoundOrcSemantics:
>>>>> >
>>>>> > Program received signal SIGSEGV, Segmentation fault.
>>>>> > 0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > (gdb) bt
>>>>> > #0  0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>>>>> >     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>>>>> >     __last=0x6f3380, __result=0x6f3380) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >
>>>>> > >
>>>>> > (__first=..., __last=..., __result=...)
>>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>>>>> > #4  0x00007ffff52af4af in
>>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >,
>>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> > >
>>>>> > >
>>>>> > (__first=..., __last=..., __result=...) at
>>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>>>>> > std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>>>>> >     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
>>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x960f90) at
>>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x960f90) at
>>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
>>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
>>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>>>>> > /home/steven/csound/csound6/Top/csound.c:888
>>>>> > #12 0x00007ffff6f3adf2 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #13 0x00007ffff6f3ae45 in exit () from
>>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>>>> > #15 0x0000000000400c39 in _start ()
>>>>> >
>>>>> >
>>>>> > with testCircularBuffer:
>>>>> >
>>>>> > Program received signal SIGSEGV, Segmentation fault.
>>>>> > 0x00007ffff793d9b0 in csoundReadCircularBuffer
>>>>> > (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>>>>> >     items=16) at
>>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>>>>> > 67        int itemsread, numelem = ((circular_buffer *)p)->numelem;
>>>>> > (gdb) bt
>>>>> > #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
>>>>> > (csound=0x4383800043830000, p=0x4382800043820000, out=0x7fffffffd960,
>>>>> >     items=16) at
>>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>>>>> > #1  0x0000000000400fca in test_read_write_diff_size ()
>>>>> >     at
>>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
>>>>> > #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
>>>>> > #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
>>>>> > #4  0x00007ffff76bb6e8 in CU_run_all_tests () from
>>>>> > /usr/lib/libcunit.so.1
>>>>> > #5  0x0000000000401673 in main () at
>>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>>>>> >
>>>>> > On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera
>>>>> > <mantaraya36@gmail.com> wrote:
>>>>> >> But then you don't have the Lua opcodes...
>>>>> >>
>>>>> >> I'll look again at the signal flow opcodes to see if it's a problem
>>>>> >> on my
>>>>> >> end.
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Andrés
>>>>> >>
>>>>> >>
>>>>> >> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini
>>>>> >> <Victor.Lazzarini@nuim.ie>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> I just ran the testCsoundTypeSystem here, it appears to pass
>>>>> >>> alright:
>>>>> >>>
>>>>> >>> coltrane:c victor$ ./testCsoundTypeSystem
>>>>> >>>
>>>>> >>>
>>>>> >>>      CUnit - A unit testing framework for C - Version 2.1-2
>>>>> >>>      http://cunit.sourceforge.net/
>>>>> >>>
>>>>> >>>
>>>>> >>> Suite: Type System Tests
>>>>> >>>   Test: Test Type System ...virtual_keyboard real time MIDI plugin
>>>>> >>> for
>>>>> >>> Csound
>>>>> >>> 0dBFS level = 32768.0
>>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>>>>> >>> libsndfile-1.0.21
>>>>> >>> passed
>>>>> >>>   Test: Test getVarSimpleName ...virtual_keyboard real time MIDI
>>>>> >>> plugin
>>>>> >>> for Csound
>>>>> >>> 0dBFS level = 32768.0
>>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>>>>> >>> libsndfile-1.0.21
>>>>> >>> passed
>>>>> >>>
>>>>> >>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>>>>> >>>               suites      1      1    n/a      0        0
>>>>> >>>                tests      2      2      2      0        0
>>>>> >>>              asserts      9      9      9      0      n/a
>>>>> >>>
>>>>> >>> Elapsed time =    0.061 seconds
>>>>> >>> end of score.   overall amps:      0.0
>>>>> >>>   overall samples out of range:        0
>>>>> >>> 0 errors in performance
>>>>> >>> Elapsed time at end of performance: real: 0.251s, CPU: 0.001s
>>>>> >>> end of score.   overall amps:      0.0
>>>>> >>>   overall samples out of range:        0
>>>>> >>> 0 errors in performance
>>>>> >>> Elapsed time at end of performance: real: 0.316s, CPU: 0.020s
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>>>>> >>>
>>>>> >>> You can use the test programs to check:
>>>>> >>> testChannels will run fine, but testCsoundTypeSystem will fail.
>>>>> >>>
>>>>> >>> Cheers,
>>>>> >>> Andrés
>>>>> >>>
>>>>> >>>
>>>>> >>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com>
>>>>> >>> wrote:
>>>>> >>>>
>>>>> >>>> Hi Andres,
>>>>> >>>>
>>>>> >>>> Thanks for following up on that.  Yes, I think we need to ensure
>>>>> >>>> that
>>>>> >>>> these are not going to crash on multiple renders.  Do you or
>>>>> >>>> anyone
>>>>> >>>> else have time to write a quick .c program that will render a csd
>>>>> >>>> multiple times so that we can reproduce the crash and trace with
>>>>> >>>> GDB
>>>>> >>>> easily?  (I need to look at other things for the next bit of my
>>>>> >>>> work
>>>>> >>>> time, but can help debug/test later)
>>>>> >>>>
>>>>> >>>> Thanks!
>>>>> >>>> steven
>>>>> >>>>
>>>>> >>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera
>>>>> >>>> <mantaraya36@gmail.com>
>>>>> >>>> wrote:
>>>>> >>>> > Hi Steven,
>>>>> >>>> >
>>>>> >>>> > It was solved for me by removing libLuaOpcodes... :P
>>>>> >>>> > BTW, I'm having a similar issue with libsignalflow opcodes, so
>>>>> >>>> > I've had
>>>>> >>>> > to
>>>>> >>>> > take those out as well. They seem not to be cleaning up
>>>>> >>>> > correctly. I
>>>>> >>>> > think
>>>>> >>>> > it's important to fix these before release or not include them
>>>>> >>>> > in
>>>>> >>>> > installers
>>>>> >>>> > as they will crash all hosts that do more than one run.
>>>>> >>>> >
>>>>> >>>> > Cheers,
>>>>> >>>> > Andrés
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi <stevenyi@gmail.com>
>>>>> >>>> > wrote:
>>>>> >>>> >>
>>>>> >>>> >> Hi All,
>>>>> >>>> >>
>>>>> >>>> >> I've taken a look at the changes from Michael. For Android, to
>>>>> >>>> >> get
>>>>> >>>> >> things working to use downloadDependencies.sh and build-all.sh,
>>>>> >>>> >> I made
>>>>> >>>> >> the following modifications:
>>>>> >>>> >>
>>>>> >>>> >> 1. I updated the fluidsynth-android Bitbucket repository with
>>>>> >>>> >> the
>>>>> >>>> >> Application.mk and Android.mk that MIchael recently committed,
>>>>> >>>> >> and
>>>>> >>>> >> consequently removed the ones from Csound6's git repo.  This
>>>>> >>>> >> means the
>>>>> >>>> >> repo for fluidsynth-android will have the most up to date
>>>>> >>>> >> files.
>>>>> >>>> >>
>>>>> >>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>>>>> >>>> >> downloadDependencies.sh now copies over the jni folder from
>>>>> >>>> >> plugins/patches/luajit-2.0 to the place where it checked out
>>>>> >>>> >> from GIT
>>>>> >>>> >> for luajit.
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >> I did some further testing about plugins and I think at this
>>>>> >>>> >> point,
>>>>> >>>> >> the crashing problem on my device is not with loading of libs
>>>>> >>>> >> but
>>>>> >>>> >> specifically the Lua opcodes.  If I remove just that library, I
>>>>> >>>> >> can
>>>>> >>>> >> load/reload/render multiple times without crashes.  I believe
>>>>> >>>> >> Andres
>>>>> >>>> >> had posted an issue where the Lua opcodes was crashing on load
>>>>> >>>> >> for his
>>>>> >>>> >> system but that seems to be resolved for him.  I haven't found
>>>>> >>>> >> a good
>>>>> >>>> >> way to debug this on Android (I haven't gotten ndk-gdb to
>>>>> >>>> >> connect).
>>>>> >>>> >>
>>>>> >>>> >> Thanks!
>>>>> >>>> >> steven
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >> ------------------------------------------------------------------------------
>>>>> >>>> >> This SF.net email is sponsored by Windows:
>>>>> >>>> >>
>>>>> >>>> >> Build for Windows Store.
>>>>> >>>> >>
>>>>> >>>> >> http://p.sf.net/sfu/windows-dev2dev
>>>>> >>>> >> _______________________________________________
>>>>> >>>> >> Csound-devel mailing list
>>>>> >>>> >> Csound-devel@lists.sourceforge.net
>>>>> >>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> > ------------------------------------------------------------------------------
>>>>> >>>> > This SF.net email is sponsored by Windows:
>>>>> >>>> >
>>>>> >>>> > Build for Windows Store.
>>>>> >>>> >
>>>>> >>>> > http://p.sf.net/sfu/windows-dev2dev
>>>>> >>>> > _______________________________________________
>>>>> >>>> > Csound-devel mailing list
>>>>> >>>> > Csound-devel@lists.sourceforge.net
>>>>> >>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>> >
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> ------------------------------------------------------------------------------
>>>>> >>>> This SF.net email is sponsored by Windows:
>>>>> >>>>
>>>>> >>>> Build for Windows Store.
>>>>> >>>>
>>>>> >>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> >>>> _______________________________________________
>>>>> >>>> Csound-devel mailing list
>>>>> >>>> Csound-devel@lists.sourceforge.net
>>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> ------------------------------------------------------------------------------
>>>>> >>> This SF.net email is sponsored by Windows:
>>>>> >>>
>>>>> >>> Build for Windows Store.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>>>>> >>> Csound-devel mailing list
>>>>> >>> Csound-devel@lists.sourceforge.net
>>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>
>>>>> >>>
>>>>> >>> Dr Victor Lazzarini
>>>>> >>> Senior Lecturer
>>>>> >>> Dept. of Music
>>>>> >>> NUI Maynooth Ireland
>>>>> >>> tel.: +353 1 708 3545
>>>>> >>> Victor dot Lazzarini AT nuim dot ie
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> ------------------------------------------------------------------------------
>>>>> >>> This SF.net email is sponsored by Windows:
>>>>> >>>
>>>>> >>> Build for Windows Store.
>>>>> >>>
>>>>> >>> http://p.sf.net/sfu/windows-dev2dev
>>>>> >>> _______________________________________________
>>>>> >>> Csound-devel mailing list
>>>>> >>> Csound-devel@lists.sourceforge.net
>>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ------------------------------------------------------------------------------
>>>>> >> This SF.net email is sponsored by Windows:
>>>>> >>
>>>>> >> Build for Windows Store.
>>>>> >>
>>>>> >> http://p.sf.net/sfu/windows-dev2dev
>>>>> >> _______________________________________________
>>>>> >> Csound-devel mailing list
>>>>> >> Csound-devel@lists.sourceforge.net
>>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Windows:
>>>>>
>>>>> Build for Windows Store.
>>>>>
>>>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Windows:
>>>>
>>>> Build for Windows Store.
>>>>
>>>> http://p.sf.net/sfu/windows-dev2dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Michael,

I've pushed a workaround fix.  I'm able to do multiple renders on
Android and no longer get a crash on Linux. I'm still not sure what
the root cause of the original problem is, but I suspect that once
atexit is called, somehow the static memory for the lua states is
wiped.  It's odd since we're in the same thread id, but that's as far
as I can imagine as a guess.  Anyways, the code does make more sense
to me that if it's == to end(), not to try to erase anyways.

At least for now this prevents crashes. I can render multiple times
with Lua_ScoreGen and trapped on Android.  I have no idea if this
introduces a memory leak at all; maybe you can take a look as my C++
skills are not up to par to diagnose this.

Otherwise, I'm at least glad that this is working.  I'd like to get
confirmation from Andres on Linux and would also like if you could
post a new Android build and we can get confirmation from others with
Android.  Seems though we're getting closer for a release. :)

Thanks!
steven

On Mon, Jul 8, 2013 at 1:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
> I tried with a fresh build from GIT.
>
> BTW: perhaps a hint, I put a breakpoint in the == function (line 122,
> LuaCsound.cpp).  When the manageLuaState with 'C' is called on LInux,
> this gets called from the STL find, and I get this:
>
> (gdb) print a.thread
> $17 = 6311936
> (gdb) print b.thread
> $18 = 140737353996128
>
> So the threads are no longer matching up by the time 'C' is called.
> During the initial 5 'O' calls, I get this:
>
> Breakpoint 3, operator== (a=..., b=...)
>     at /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:122
> 122    if (pthread_equal(a.thread, b.thread)) {
> (gdb) print a.thread
> $19 = 140737353996128
> (gdb) print b.thread
> $20 = 140737353996128
>
>
> Note, I'm pretty sure a in this case is the value held within the
> vector, as printing luaStateForThread.thread in the manageLuaState
> funciton shows the long thread id.
>
>
>
> On Mon, Jul 8, 2013 at 12:40 PM, Michael Gogins
> <michael.gogins@gmail.com> wrote:
>> Did you try from a fresh build or from a SourceForge app download? I haven't
>> updated the latter with my fix yet.
>>
>> Regards,
>> Mike
>>
>>
>> ===========================
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Jul 8, 2013 at 12:32 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>
>>> Hi Michael,
>>>
>>> I just tried CSDPlayer and it's still crashing.  I imagine Linux will
>>> still crash since this change doesn't apply for it there.
>>>
>>> I wonder if there's some weird issue with how static is treated on
>>> *nix with gcc (which would apply to Linux and Android both). Seems
>>> like a longshot but I'm really not sure what's going on. :)   I'm
>>> catching up a bit today on things before heading back to unpacking,
>>> but will try to do some further gdb diagnosis on Linux.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 6, 2013 at 12:24 PM, Michael Gogins
>>> <michael.gogins@gmail.com> wrote:
>>> > I have pushed code to call csoundInitialize(CSOUNDINIT_NO_ATEXIT) in
>>> > CSDPlayer's static initialization block. As I understand it, this
>>> > function
>>> > only needs to be called once in process, is that correct?
>>> >
>>> > By the way, Steven, thanks for doing the patches directory.
>>> >
>>> > Regards,
>>> > Mike
>>> >
>>> >
>>> > ===========================
>>> > Michael Gogins
>>> > Irreducible Productions
>>> > http://michaelgogins.tumblr.com
>>> > Michael dot Gogins at gmail dot com
>>> >
>>> >
>>> > On Sat, Jul 6, 2013 at 11:44 AM, Michael Gogins
>>> > <michael.gogins@gmail.com>
>>> > wrote:
>>> >>
>>> >> I changed the code some time ago so that this atexit stuff would not be
>>> >> called on WIndows, because it always caused a crash on exit and I had
>>> >> no
>>> >> idea how to fix it.
>>> >>
>>> >> On Android, the NDK docs advise allowing Android itself to do all
>>> >> cleanup
>>> >> on exit, so I will change the CsoundAndroid  or CSDPlayuer code,
>>> >> whichever
>>> >> is most appropraite, to pass the CSOUNDINIT_NO_ATEXIT flag to
>>> >> csoundInitialize. Or something to avoid the atexit stuff on Android.
>>> >>
>>> >> I don't know why I don't see this bug on the Galaxy S4.
>>> >>
>>> >> Regards,
>>> >> Mike
>>> >>
>>> >>
>>> >> ===========================
>>> >> Michael Gogins
>>> >> Irreducible Productions
>>> >> http://michaelgogins.tumblr.com
>>> >> Michael dot Gogins at gmail dot com
>>> >>
>>> >>
>>> >> On Sat, Jul 6, 2013 at 10:49 AM, Andres Cabrera <mantaraya36@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Yes, these are the issues I'm having. I think they don't occur on
>>> >>> windows
>>> >>> because there is no function registered with atexit (see
>>> >>> csoundInitialize),
>>> >>> but I'm not sure why it's not crashing on Os X.
>>> >>>
>>> >>> Cheers,
>>> >>> Andres
>>> >>>
>>> >>> On Jul 5, 2013 7:03 PM, "Michael Gogins" <michael.gogins@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> I'm happy to help, the information supplied will be helpful.
>>> >>>> Unfortunately, I don't get this crash here... but I can probably
>>> >>>> figure out
>>> >>>> what is going on. The module cleanup function is probably not being
>>> >>>> called.
>>> >>>> I'll see if there's a workaround or if it is being called at an
>>> >>>> inopportune
>>> >>>> time, or I'll just preallocate a fixed number of Lua states (one per
>>> >>>> Csound
>>> >>>> thread) and keep them around. Something.
>>> >>>>
>>> >>>> Regards,
>>> >>>> Mike
>>> >>>>
>>> >>>>
>>> >>>> ===========================
>>> >>>> Michael Gogins
>>> >>>> Irreducible Productions
>>> >>>> http://michaelgogins.tumblr.com
>>> >>>> Michael dot Gogins at gmail dot com
>>> >>>>
>>> >>>>
>>> >>>> On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>> >>>>>
>>> >>>>> Just some follow up, I had put a breakpoint on manageLuaState. Using
>>> >>>>> testCsoundOrcSemantics, I saw five calls with "O" during the tests,
>>> >>>>> then ctest printed its report, then with the call to manageLuaState
>>> >>>>> with "C", I get the crash with the call to erase.
>>> >>>>>
>>> >>>>> I'm not used to debugging C++, but what I'm seeing is that the
>>> >>>>> iterator it during the "O" calls is:
>>> >>>>>
>>> >>>>> {_M_current = 0x6f3370}
>>> >>>>>
>>> >>>>> but on the "C" call I see:
>>> >>>>>
>>> >>>>> {_M_current = 0x6f3380}
>>> >>>>>
>>> >>>>> which is equal to the luaStatesForThreads.end().
>>> >>>>>
>>> >>>>> So... I'm not sure what's going on.  Perhaps Michael could help
>>> >>>>> debug/test.  I also don't know if this is the cause of the issue on
>>> >>>>> Android as I haven't been able to really get gdb going there.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com>
>>> >>>>> wrote:
>>> >>>>> > I ran "make test" on a Debian system and I get 3 failures.  CTest
>>> >>>>> > reports 2 of them are failed tests and one is a segfault. I ran
>>> >>>>> > the
>>> >>>>> > failed tests with gdb and got:
>>> >>>>> >
>>> >>>>> > with testCsoundTypeSystem:
>>> >>>>> >
>>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>>> >>>>> > 0x00007ffff702b806 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > (gdb) bt
>>> >>>>> > #0  0x00007ffff702b806 in ?? () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>>> >>>>> >     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>>> >>>>> >     __last=0x6f01e0, __result=0x6f01e0) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >
>>> >>>>> > >
>>> >>>>> > (__first=..., __last=..., __result=...)
>>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>>> >>>>> > #4  0x00007ffff52af4af in
>>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >
>>> >>>>> > >
>>> >>>>> > (__first=..., __last=..., __result=...) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>>> >>>>> > std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>>> >>>>> >     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
>>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x6fa860) at
>>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x6fa860)
>>> >>>>> > at
>>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #15 0x0000000000400bf9 in _start ()
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > with testCsoundOrcSemantics:
>>> >>>>> >
>>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>>> >>>>> > 0x00007ffff702b7fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > (gdb) bt
>>> >>>>> > #0  0x00007ffff702b7fc in ?? () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread> (
>>> >>>>> >     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>>> >>>>> >     __last=0x6f3380, __result=0x6f3380) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >
>>> >>>>> > >
>>> >>>>> > (__first=..., __last=..., __result=...)
>>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>>> >>>>> > #4  0x00007ffff52af4af in
>>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >,
>>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>>> >>>>> > std::vector<LuaStateForThread, std::allocator<LuaStateForThread> >
>>> >>>>> > >
>>> >>>>> > >
>>> >>>>> > (__first=..., __last=..., __result=...) at
>>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>>> >>>>> > std::allocator<LuaStateForThread> >::erase (this=0x7ffff54b67a0,
>>> >>>>> >     __position=...) at /usr/include/c++/4.7/bits/vector.tcc:139
>>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy (csound=0x960f90) at
>>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules (csound=0x960f90)
>>> >>>>> > at
>>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>>> >>>>> > #15 0x0000000000400c39 in _start ()
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > with testCircularBuffer:
>>> >>>>> >
>>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>>> >>>>> > 0x00007ffff793d9b0 in csoundReadCircularBuffer
>>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>>> >>>>> > out=0x7fffffffd960,
>>> >>>>> >     items=16) at
>>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>>> >>>>> > 67        int itemsread, numelem = ((circular_buffer
>>> >>>>> > *)p)->numelem;
>>> >>>>> > (gdb) bt
>>> >>>>> > #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
>>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>>> >>>>> > out=0x7fffffffd960,
>>> >>>>> >     items=16) at
>>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>>> >>>>> > #1  0x0000000000400fca in test_read_write_diff_size ()
>>> >>>>> >     at
>>> >>>>> >
>>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
>>> >>>>> > #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
>>> >>>>> > #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
>>> >>>>> > #4  0x00007ffff76bb6e8 in CU_run_all_tests () from
>>> >>>>> > /usr/lib/libcunit.so.1
>>> >>>>> > #5  0x0000000000401673 in main () at
>>> >>>>> >
>>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>>> >>>>> >
>>> >>>>> > On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera
>>> >>>>> > <mantaraya36@gmail.com> wrote:
>>> >>>>> >> But then you don't have the Lua opcodes...
>>> >>>>> >>
>>> >>>>> >> I'll look again at the signal flow opcodes to see if it's a
>>> >>>>> >> problem
>>> >>>>> >> on my
>>> >>>>> >> end.
>>> >>>>> >>
>>> >>>>> >> Cheers,
>>> >>>>> >> Andrés
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini
>>> >>>>> >> <Victor.Lazzarini@nuim.ie>
>>> >>>>> >> wrote:
>>> >>>>> >>>
>>> >>>>> >>> I just ran the testCsoundTypeSystem here, it appears to pass
>>> >>>>> >>> alright:
>>> >>>>> >>>
>>> >>>>> >>> coltrane:c victor$ ./testCsoundTypeSystem
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>      CUnit - A unit testing framework for C - Version 2.1-2
>>> >>>>> >>>      http://cunit.sourceforge.net/
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> Suite: Type System Tests
>>> >>>>> >>>   Test: Test Type System ...virtual_keyboard real time MIDI
>>> >>>>> >>> plugin
>>> >>>>> >>> for
>>> >>>>> >>> Csound
>>> >>>>> >>> 0dBFS level = 32768.0
>>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>>> >>>>> >>> libsndfile-1.0.21
>>> >>>>> >>> passed
>>> >>>>> >>>   Test: Test getVarSimpleName ...virtual_keyboard real time MIDI
>>> >>>>> >>> plugin
>>> >>>>> >>> for Csound
>>> >>>>> >>> 0dBFS level = 32768.0
>>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>>> >>>>> >>> libsndfile-1.0.21
>>> >>>>> >>> passed
>>> >>>>> >>>
>>> >>>>> >>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>>> >>>>> >>>               suites      1      1    n/a      0        0
>>> >>>>> >>>                tests      2      2      2      0        0
>>> >>>>> >>>              asserts      9      9      9      0      n/a
>>> >>>>> >>>
>>> >>>>> >>> Elapsed time =    0.061 seconds
>>> >>>>> >>> end of score.   overall amps:      0.0
>>> >>>>> >>>   overall samples out of range:        0
>>> >>>>> >>> 0 errors in performance
>>> >>>>> >>> Elapsed time at end of performance: real: 0.251s, CPU: 0.001s
>>> >>>>> >>> end of score.   overall amps:      0.0
>>> >>>>> >>>   overall samples out of range:        0
>>> >>>>> >>> 0 errors in performance
>>> >>>>> >>> Elapsed time at end of performance: real: 0.316s, CPU: 0.020s
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>>> >>>>> >>>
>>> >>>>> >>> You can use the test programs to check:
>>> >>>>> >>> testChannels will run fine, but testCsoundTypeSystem will fail.
>>> >>>>> >>>
>>> >>>>> >>> Cheers,
>>> >>>>> >>> Andrés
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi <stevenyi@gmail.com>
>>> >>>>> >>> wrote:
>>> >>>>> >>>>
>>> >>>>> >>>> Hi Andres,
>>> >>>>> >>>>
>>> >>>>> >>>> Thanks for following up on that.  Yes, I think we need to
>>> >>>>> >>>> ensure
>>> >>>>> >>>> that
>>> >>>>> >>>> these are not going to crash on multiple renders.  Do you or
>>> >>>>> >>>> anyone
>>> >>>>> >>>> else have time to write a quick .c program that will render a
>>> >>>>> >>>> csd
>>> >>>>> >>>> multiple times so that we can reproduce the crash and trace
>>> >>>>> >>>> with
>>> >>>>> >>>> GDB
>>> >>>>> >>>> easily?  (I need to look at other things for the next bit of my
>>> >>>>> >>>> work
>>> >>>>> >>>> time, but can help debug/test later)
>>> >>>>> >>>>
>>> >>>>> >>>> Thanks!
>>> >>>>> >>>> steven
>>> >>>>> >>>>
>>> >>>>> >>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera
>>> >>>>> >>>> <mantaraya36@gmail.com>
>>> >>>>> >>>> wrote:
>>> >>>>> >>>> > Hi Steven,
>>> >>>>> >>>> >
>>> >>>>> >>>> > It was solved for me by removing libLuaOpcodes... :P
>>> >>>>> >>>> > BTW, I'm having a similar issue with libsignalflow opcodes,
>>> >>>>> >>>> > so
>>> >>>>> >>>> > I've had
>>> >>>>> >>>> > to
>>> >>>>> >>>> > take those out as well. They seem not to be cleaning up
>>> >>>>> >>>> > correctly. I
>>> >>>>> >>>> > think
>>> >>>>> >>>> > it's important to fix these before release or not include
>>> >>>>> >>>> > them
>>> >>>>> >>>> > in
>>> >>>>> >>>> > installers
>>> >>>>> >>>> > as they will crash all hosts that do more than one run.
>>> >>>>> >>>> >
>>> >>>>> >>>> > Cheers,
>>> >>>>> >>>> > Andrés
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi
>>> >>>>> >>>> > <stevenyi@gmail.com>
>>> >>>>> >>>> > wrote:
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> Hi All,
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> I've taken a look at the changes from Michael. For Android,
>>> >>>>> >>>> >> to
>>> >>>>> >>>> >> get
>>> >>>>> >>>> >> things working to use downloadDependencies.sh and
>>> >>>>> >>>> >> build-all.sh,
>>> >>>>> >>>> >> I made
>>> >>>>> >>>> >> the following modifications:
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> 1. I updated the fluidsynth-android Bitbucket repository
>>> >>>>> >>>> >> with
>>> >>>>> >>>> >> the
>>> >>>>> >>>> >> Application.mk and Android.mk that MIchael recently
>>> >>>>> >>>> >> committed,
>>> >>>>> >>>> >> and
>>> >>>>> >>>> >> consequently removed the ones from Csound6's git repo.  This
>>> >>>>> >>>> >> means the
>>> >>>>> >>>> >> repo for fluidsynth-android will have the most up to date
>>> >>>>> >>>> >> files.
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>>> >>>>> >>>> >> downloadDependencies.sh now copies over the jni folder from
>>> >>>>> >>>> >> plugins/patches/luajit-2.0 to the place where it checked out
>>> >>>>> >>>> >> from GIT
>>> >>>>> >>>> >> for luajit.
>>> >>>>> >>>> >>
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> I did some further testing about plugins and I think at this
>>> >>>>> >>>> >> point,
>>> >>>>> >>>> >> the crashing problem on my device is not with loading of
>>> >>>>> >>>> >> libs
>>> >>>>> >>>> >> but
>>> >>>>> >>>> >> specifically the Lua opcodes.  If I remove just that
>>> >>>>> >>>> >> library, I
>>> >>>>> >>>> >> can
>>> >>>>> >>>> >> load/reload/render multiple times without crashes.  I
>>> >>>>> >>>> >> believe
>>> >>>>> >>>> >> Andres
>>> >>>>> >>>> >> had posted an issue where the Lua opcodes was crashing on
>>> >>>>> >>>> >> load
>>> >>>>> >>>> >> for his
>>> >>>>> >>>> >> system but that seems to be resolved for him.  I haven't
>>> >>>>> >>>> >> found
>>> >>>>> >>>> >> a good
>>> >>>>> >>>> >> way to debug this on Android (I haven't gotten ndk-gdb to
>>> >>>>> >>>> >> connect).
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> Thanks!
>>> >>>>> >>>> >> steven
>>> >>>>> >>>> >>
>>> >>>>> >>>> >>
>>> >>>>> >>>> >>
>>> >>>>> >>>> >>
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> ------------------------------------------------------------------------------
>>> >>>>> >>>> >> This SF.net email is sponsored by Windows:
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> Build for Windows Store.
>>> >>>>> >>>> >>
>>> >>>>> >>>> >> http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> >>>> >> _______________________________________________
>>> >>>>> >>>> >> Csound-devel mailing list
>>> >>>>> >>>> >> Csound-devel@lists.sourceforge.net
>>> >>>>> >>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> >
>>> >>>>> >>>> > ------------------------------------------------------------------------------
>>> >>>>> >>>> > This SF.net email is sponsored by Windows:
>>> >>>>> >>>> >
>>> >>>>> >>>> > Build for Windows Store.
>>> >>>>> >>>> >
>>> >>>>> >>>> > http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> >>>> > _______________________________________________
>>> >>>>> >>>> > Csound-devel mailing list
>>> >>>>> >>>> > Csound-devel@lists.sourceforge.net
>>> >>>>> >>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>>> >
>>> >>>>> >>>>
>>> >>>>> >>>>
>>> >>>>> >>>>
>>> >>>>> >>>>
>>> >>>>> >>>> ------------------------------------------------------------------------------
>>> >>>>> >>>> This SF.net email is sponsored by Windows:
>>> >>>>> >>>>
>>> >>>>> >>>> Build for Windows Store.
>>> >>>>> >>>>
>>> >>>>> >>>> http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> >>>> _______________________________________________
>>> >>>>> >>>> Csound-devel mailing list
>>> >>>>> >>>> Csound-devel@lists.sourceforge.net
>>> >>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> ------------------------------------------------------------------------------
>>> >>>>> >>> This SF.net email is sponsored by Windows:
>>> >>>>> >>>
>>> >>>>> >>> Build for Windows Store.
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>>> >>>>> >>> Csound-devel mailing list
>>> >>>>> >>> Csound-devel@lists.sourceforge.net
>>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> Dr Victor Lazzarini
>>> >>>>> >>> Senior Lecturer
>>> >>>>> >>> Dept. of Music
>>> >>>>> >>> NUI Maynooth Ireland
>>> >>>>> >>> tel.: +353 1 708 3545
>>> >>>>> >>> Victor dot Lazzarini AT nuim dot ie
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >>> ------------------------------------------------------------------------------
>>> >>>>> >>> This SF.net email is sponsored by Windows:
>>> >>>>> >>>
>>> >>>>> >>> Build for Windows Store.
>>> >>>>> >>>
>>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> >>> _______________________________________________
>>> >>>>> >>> Csound-devel mailing list
>>> >>>>> >>> Csound-devel@lists.sourceforge.net
>>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >> ------------------------------------------------------------------------------
>>> >>>>> >> This SF.net email is sponsored by Windows:
>>> >>>>> >>
>>> >>>>> >> Build for Windows Store.
>>> >>>>> >>
>>> >>>>> >> http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> >> _______________________________________________
>>> >>>>> >> Csound-devel mailing list
>>> >>>>> >> Csound-devel@lists.sourceforge.net
>>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>> >>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ------------------------------------------------------------------------------
>>> >>>>> This SF.net email is sponsored by Windows:
>>> >>>>>
>>> >>>>> Build for Windows Store.
>>> >>>>>
>>> >>>>> http://p.sf.net/sfu/windows-dev2dev
>>> >>>>> _______________________________________________
>>> >>>>> Csound-devel mailing list
>>> >>>>> Csound-devel@lists.sourceforge.net
>>> >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> ------------------------------------------------------------------------------
>>> >>>> This SF.net email is sponsored by Windows:
>>> >>>>
>>> >>>> Build for Windows Store.
>>> >>>>
>>> >>>> http://p.sf.net/sfu/windows-dev2dev
>>> >>>> _______________________________________________
>>> >>>> Csound-devel mailing list
>>> >>>> Csound-devel@lists.sourceforge.net
>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> This SF.net email is sponsored by Windows:
>>> >>>
>>> >>> Build for Windows Store.
>>> >>>
>>> >>> http://p.sf.net/sfu/windows-dev2dev
>>> >>> _______________________________________________
>>> >>> Csound-devel mailing list
>>> >>> Csound-devel@lists.sourceforge.net
>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > This SF.net email is sponsored by Windows:
>>> >
>>> > Build for Windows Store.
>>> >
>>> > http://p.sf.net/sfu/windows-dev2dev
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Just a note, I realized I hadn't pushed the change (git was waiting
for me to enter password).  I just pushed the change now, thanks!

On Mon, Jul 8, 2013 at 3:34 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
> Erasing at end() would be a bug and should crash! If so mea culpa.
>
> My own workaround is simply to avoid calling atexit.
>
> I am investigating further. One this is for sure, process lifecycle and
> handling are VERY different on Android. In general, apps don't know whether
> they are alive or dead. The OS keeps pushing apps that the user doesn't
> interact with further into the grave. Generally, apps don't exit because the
> user did anything but because the OS kills them.
>
> POSIX also gives no precise guarantees about the order of things at exit.
>
> I would prefer to let the OS clean up unless we have locks that it can't
> unlock. I'll review your code re: memory leaks, but if this is at exit, not
> to worry.
>
> I will post a new build tonight.
>
> Regards,
> Mike
>
>
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Jul 8, 2013 at 2:04 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> Hi Michael,
>>
>> I've pushed a workaround fix.  I'm able to do multiple renders on
>> Android and no longer get a crash on Linux. I'm still not sure what
>> the root cause of the original problem is, but I suspect that once
>> atexit is called, somehow the static memory for the lua states is
>> wiped.  It's odd since we're in the same thread id, but that's as far
>> as I can imagine as a guess.  Anyways, the code does make more sense
>> to me that if it's == to end(), not to try to erase anyways.
>>
>> At least for now this prevents crashes. I can render multiple times
>> with Lua_ScoreGen and trapped on Android.  I have no idea if this
>> introduces a memory leak at all; maybe you can take a look as my C++
>> skills are not up to par to diagnose this.
>>
>> Otherwise, I'm at least glad that this is working.  I'd like to get
>> confirmation from Andres on Linux and would also like if you could
>> post a new Android build and we can get confirmation from others with
>> Android.  Seems though we're getting closer for a release. :)
>>
>> Thanks!
>> steven
>>
>> On Mon, Jul 8, 2013 at 1:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> > I tried with a fresh build from GIT.
>> >
>> > BTW: perhaps a hint, I put a breakpoint in the == function (line 122,
>> > LuaCsound.cpp).  When the manageLuaState with 'C' is called on LInux,
>> > this gets called from the STL find, and I get this:
>> >
>> > (gdb) print a.thread
>> > $17 = 6311936
>> > (gdb) print b.thread
>> > $18 = 140737353996128
>> >
>> > So the threads are no longer matching up by the time 'C' is called.
>> > During the initial 5 'O' calls, I get this:
>> >
>> > Breakpoint 3, operator== (a=..., b=...)
>> >     at /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:122
>> > 122    if (pthread_equal(a.thread, b.thread)) {
>> > (gdb) print a.thread
>> > $19 = 140737353996128
>> > (gdb) print b.thread
>> > $20 = 140737353996128
>> >
>> >
>> > Note, I'm pretty sure a in this case is the value held within the
>> > vector, as printing luaStateForThread.thread in the manageLuaState
>> > funciton shows the long thread id.
>> >
>> >
>> >
>> > On Mon, Jul 8, 2013 at 12:40 PM, Michael Gogins
>> > <michael.gogins@gmail.com> wrote:
>> >> Did you try from a fresh build or from a SourceForge app download? I
>> >> haven't
>> >> updated the latter with my fix yet.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >>
>> >> ===========================
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Mon, Jul 8, 2013 at 12:32 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> >>>
>> >>> Hi Michael,
>> >>>
>> >>> I just tried CSDPlayer and it's still crashing.  I imagine Linux will
>> >>> still crash since this change doesn't apply for it there.
>> >>>
>> >>> I wonder if there's some weird issue with how static is treated on
>> >>> *nix with gcc (which would apply to Linux and Android both). Seems
>> >>> like a longshot but I'm really not sure what's going on. :)   I'm
>> >>> catching up a bit today on things before heading back to unpacking,
>> >>> but will try to do some further gdb diagnosis on Linux.
>> >>>
>> >>> Thanks!
>> >>> steven
>> >>>
>> >>> On Sat, Jul 6, 2013 at 12:24 PM, Michael Gogins
>> >>> <michael.gogins@gmail.com> wrote:
>> >>> > I have pushed code to call csoundInitialize(CSOUNDINIT_NO_ATEXIT) in
>> >>> > CSDPlayer's static initialization block. As I understand it, this
>> >>> > function
>> >>> > only needs to be called once in process, is that correct?
>> >>> >
>> >>> > By the way, Steven, thanks for doing the patches directory.
>> >>> >
>> >>> > Regards,
>> >>> > Mike
>> >>> >
>> >>> >
>> >>> > ===========================
>> >>> > Michael Gogins
>> >>> > Irreducible Productions
>> >>> > http://michaelgogins.tumblr.com
>> >>> > Michael dot Gogins at gmail dot com
>> >>> >
>> >>> >
>> >>> > On Sat, Jul 6, 2013 at 11:44 AM, Michael Gogins
>> >>> > <michael.gogins@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> I changed the code some time ago so that this atexit stuff would
>> >>> >> not be
>> >>> >> called on WIndows, because it always caused a crash on exit and I
>> >>> >> had
>> >>> >> no
>> >>> >> idea how to fix it.
>> >>> >>
>> >>> >> On Android, the NDK docs advise allowing Android itself to do all
>> >>> >> cleanup
>> >>> >> on exit, so I will change the CsoundAndroid  or CSDPlayuer code,
>> >>> >> whichever
>> >>> >> is most appropraite, to pass the CSOUNDINIT_NO_ATEXIT flag to
>> >>> >> csoundInitialize. Or something to avoid the atexit stuff on
>> >>> >> Android.
>> >>> >>
>> >>> >> I don't know why I don't see this bug on the Galaxy S4.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Mike
>> >>> >>
>> >>> >>
>> >>> >> ===========================
>> >>> >> Michael Gogins
>> >>> >> Irreducible Productions
>> >>> >> http://michaelgogins.tumblr.com
>> >>> >> Michael dot Gogins at gmail dot com
>> >>> >>
>> >>> >>
>> >>> >> On Sat, Jul 6, 2013 at 10:49 AM, Andres Cabrera
>> >>> >> <mantaraya36@gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Yes, these are the issues I'm having. I think they don't occur on
>> >>> >>> windows
>> >>> >>> because there is no function registered with atexit (see
>> >>> >>> csoundInitialize),
>> >>> >>> but I'm not sure why it's not crashing on Os X.
>> >>> >>>
>> >>> >>> Cheers,
>> >>> >>> Andres
>> >>> >>>
>> >>> >>> On Jul 5, 2013 7:03 PM, "Michael Gogins"
>> >>> >>> <michael.gogins@gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> I'm happy to help, the information supplied will be helpful.
>> >>> >>>> Unfortunately, I don't get this crash here... but I can probably
>> >>> >>>> figure out
>> >>> >>>> what is going on. The module cleanup function is probably not
>> >>> >>>> being
>> >>> >>>> called.
>> >>> >>>> I'll see if there's a workaround or if it is being called at an
>> >>> >>>> inopportune
>> >>> >>>> time, or I'll just preallocate a fixed number of Lua states (one
>> >>> >>>> per
>> >>> >>>> Csound
>> >>> >>>> thread) and keep them around. Something.
>> >>> >>>>
>> >>> >>>> Regards,
>> >>> >>>> Mike
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> ===========================
>> >>> >>>> Michael Gogins
>> >>> >>>> Irreducible Productions
>> >>> >>>> http://michaelgogins.tumblr.com
>> >>> >>>> Michael dot Gogins at gmail dot com
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com>
>> >>> >>>> wrote:
>> >>> >>>>>
>> >>> >>>>> Just some follow up, I had put a breakpoint on manageLuaState.
>> >>> >>>>> Using
>> >>> >>>>> testCsoundOrcSemantics, I saw five calls with "O" during the
>> >>> >>>>> tests,
>> >>> >>>>> then ctest printed its report, then with the call to
>> >>> >>>>> manageLuaState
>> >>> >>>>> with "C", I get the crash with the call to erase.
>> >>> >>>>>
>> >>> >>>>> I'm not used to debugging C++, but what I'm seeing is that the
>> >>> >>>>> iterator it during the "O" calls is:
>> >>> >>>>>
>> >>> >>>>> {_M_current = 0x6f3370}
>> >>> >>>>>
>> >>> >>>>> but on the "C" call I see:
>> >>> >>>>>
>> >>> >>>>> {_M_current = 0x6f3380}
>> >>> >>>>>
>> >>> >>>>> which is equal to the luaStatesForThreads.end().
>> >>> >>>>>
>> >>> >>>>> So... I'm not sure what's going on.  Perhaps Michael could help
>> >>> >>>>> debug/test.  I also don't know if this is the cause of the issue
>> >>> >>>>> on
>> >>> >>>>> Android as I haven't been able to really get gdb going there.
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com>
>> >>> >>>>> wrote:
>> >>> >>>>> > I ran "make test" on a Debian system and I get 3 failures.
>> >>> >>>>> > CTest
>> >>> >>>>> > reports 2 of them are failed tests and one is a segfault. I
>> >>> >>>>> > ran
>> >>> >>>>> > the
>> >>> >>>>> > failed tests with gdb and got:
>> >>> >>>>> >
>> >>> >>>>> > with testCsoundTypeSystem:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff702b806 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff702b806 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>> >>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread>
>> >>> >>>>> > (
>> >>> >>>>> >     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>> >>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>> >>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>> >>> >>>>> >     __last=0x6f01e0, __result=0x6f01e0) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>> >>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...)
>> >>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>> >>> >>>>> > #4  0x00007ffff52af4af in
>> >>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>> >>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >::erase
>> >>> >>>>> > (this=0x7ffff54b67a0,
>> >>> >>>>> >     __position=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/vector.tcc:139
>> >>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>> >>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy
>> >>> >>>>> > (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>> >>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules
>> >>> >>>>> > (csound=0x6fa860)
>> >>> >>>>> > at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>> >>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>> >>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>> >>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>> >>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #15 0x0000000000400bf9 in _start ()
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > with testCsoundOrcSemantics:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff702b7fc in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff702b7fc in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>> >>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread>
>> >>> >>>>> > (
>> >>> >>>>> >     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>> >>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>> >>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>> >>> >>>>> >     __last=0x6f3380, __result=0x6f3380) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>> >>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...)
>> >>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>> >>> >>>>> > #4  0x00007ffff52af4af in
>> >>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>> >>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >::erase
>> >>> >>>>> > (this=0x7ffff54b67a0,
>> >>> >>>>> >     __position=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/vector.tcc:139
>> >>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>> >>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy
>> >>> >>>>> > (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>> >>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules
>> >>> >>>>> > (csound=0x960f90)
>> >>> >>>>> > at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>> >>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>> >>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>> >>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>> >>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #15 0x0000000000400c39 in _start ()
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > with testCircularBuffer:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff793d9b0 in csoundReadCircularBuffer
>> >>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>> >>> >>>>> > out=0x7fffffffd960,
>> >>> >>>>> >     items=16) at
>> >>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>> >>> >>>>> > 67        int itemsread, numelem = ((circular_buffer
>> >>> >>>>> > *)p)->numelem;
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
>> >>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>> >>> >>>>> > out=0x7fffffffd960,
>> >>> >>>>> >     items=16) at
>> >>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>> >>> >>>>> > #1  0x0000000000400fca in test_read_write_diff_size ()
>> >>> >>>>> >     at
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
>> >>> >>>>> > #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
>> >>> >>>>> > #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
>> >>> >>>>> > #4  0x00007ffff76bb6e8 in CU_run_all_tests () from
>> >>> >>>>> > /usr/lib/libcunit.so.1
>> >>> >>>>> > #5  0x0000000000401673 in main () at
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>> >>> >>>>> >
>> >>> >>>>> > On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera
>> >>> >>>>> > <mantaraya36@gmail.com> wrote:
>> >>> >>>>> >> But then you don't have the Lua opcodes...
>> >>> >>>>> >>
>> >>> >>>>> >> I'll look again at the signal flow opcodes to see if it's a
>> >>> >>>>> >> problem
>> >>> >>>>> >> on my
>> >>> >>>>> >> end.
>> >>> >>>>> >>
>> >>> >>>>> >> Cheers,
>> >>> >>>>> >> Andrés
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini
>> >>> >>>>> >> <Victor.Lazzarini@nuim.ie>
>> >>> >>>>> >> wrote:
>> >>> >>>>> >>>
>> >>> >>>>> >>> I just ran the testCsoundTypeSystem here, it appears to pass
>> >>> >>>>> >>> alright:
>> >>> >>>>> >>>
>> >>> >>>>> >>> coltrane:c victor$ ./testCsoundTypeSystem
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>      CUnit - A unit testing framework for C - Version 2.1-2
>> >>> >>>>> >>>      http://cunit.sourceforge.net/
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> Suite: Type System Tests
>> >>> >>>>> >>>   Test: Test Type System ...virtual_keyboard real time MIDI
>> >>> >>>>> >>> plugin
>> >>> >>>>> >>> for
>> >>> >>>>> >>> Csound
>> >>> >>>>> >>> 0dBFS level = 32768.0
>> >>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>> >>> >>>>> >>> libsndfile-1.0.21
>> >>> >>>>> >>> passed
>> >>> >>>>> >>>   Test: Test getVarSimpleName ...virtual_keyboard real time
>> >>> >>>>> >>> MIDI
>> >>> >>>>> >>> plugin
>> >>> >>>>> >>> for Csound
>> >>> >>>>> >>> 0dBFS level = 32768.0
>> >>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>> >>> >>>>> >>> libsndfile-1.0.21
>> >>> >>>>> >>> passed
>> >>> >>>>> >>>
>> >>> >>>>> >>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>> >>> >>>>> >>>               suites      1      1    n/a      0        0
>> >>> >>>>> >>>                tests      2      2      2      0        0
>> >>> >>>>> >>>              asserts      9      9      9      0      n/a
>> >>> >>>>> >>>
>> >>> >>>>> >>> Elapsed time =    0.061 seconds
>> >>> >>>>> >>> end of score.   overall amps:      0.0
>> >>> >>>>> >>>   overall samples out of range:        0
>> >>> >>>>> >>> 0 errors in performance
>> >>> >>>>> >>> Elapsed time at end of performance: real: 0.251s, CPU:
>> >>> >>>>> >>> 0.001s
>> >>> >>>>> >>> end of score.   overall amps:      0.0
>> >>> >>>>> >>>   overall samples out of range:        0
>> >>> >>>>> >>> 0 errors in performance
>> >>> >>>>> >>> Elapsed time at end of performance: real: 0.316s, CPU:
>> >>> >>>>> >>> 0.020s
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>> >>> >>>>> >>>
>> >>> >>>>> >>> You can use the test programs to check:
>> >>> >>>>> >>> testChannels will run fine, but testCsoundTypeSystem will
>> >>> >>>>> >>> fail.
>> >>> >>>>> >>>
>> >>> >>>>> >>> Cheers,
>> >>> >>>>> >>> Andrés
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi
>> >>> >>>>> >>> <stevenyi@gmail.com>
>> >>> >>>>> >>> wrote:
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Hi Andres,
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Thanks for following up on that.  Yes, I think we need to
>> >>> >>>>> >>>> ensure
>> >>> >>>>> >>>> that
>> >>> >>>>> >>>> these are not going to crash on multiple renders.  Do you
>> >>> >>>>> >>>> or
>> >>> >>>>> >>>> anyone
>> >>> >>>>> >>>> else have time to write a quick .c program that will render
>> >>> >>>>> >>>> a
>> >>> >>>>> >>>> csd
>> >>> >>>>> >>>> multiple times so that we can reproduce the crash and trace
>> >>> >>>>> >>>> with
>> >>> >>>>> >>>> GDB
>> >>> >>>>> >>>> easily?  (I need to look at other things for the next bit
>> >>> >>>>> >>>> of my
>> >>> >>>>> >>>> work
>> >>> >>>>> >>>> time, but can help debug/test later)
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Thanks!
>> >>> >>>>> >>>> steven
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera
>> >>> >>>>> >>>> <mantaraya36@gmail.com>
>> >>> >>>>> >>>> wrote:
>> >>> >>>>> >>>> > Hi Steven,
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > It was solved for me by removing libLuaOpcodes... :P
>> >>> >>>>> >>>> > BTW, I'm having a similar issue with libsignalflow
>> >>> >>>>> >>>> > opcodes,
>> >>> >>>>> >>>> > so
>> >>> >>>>> >>>> > I've had
>> >>> >>>>> >>>> > to
>> >>> >>>>> >>>> > take those out as well. They seem not to be cleaning up
>> >>> >>>>> >>>> > correctly. I
>> >>> >>>>> >>>> > think
>> >>> >>>>> >>>> > it's important to fix these before release or not include
>> >>> >>>>> >>>> > them
>> >>> >>>>> >>>> > in
>> >>> >>>>> >>>> > installers
>> >>> >>>>> >>>> > as they will crash all hosts that do more than one run.
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > Cheers,
>> >>> >>>>> >>>> > Andrés
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi
>> >>> >>>>> >>>> > <stevenyi@gmail.com>
>> >>> >>>>> >>>> > wrote:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Hi All,
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> I've taken a look at the changes from Michael. For
>> >>> >>>>> >>>> >> Android,
>> >>> >>>>> >>>> >> to
>> >>> >>>>> >>>> >> get
>> >>> >>>>> >>>> >> things working to use downloadDependencies.sh and
>> >>> >>>>> >>>> >> build-all.sh,
>> >>> >>>>> >>>> >> I made
>> >>> >>>>> >>>> >> the following modifications:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> 1. I updated the fluidsynth-android Bitbucket repository
>> >>> >>>>> >>>> >> with
>> >>> >>>>> >>>> >> the
>> >>> >>>>> >>>> >> Application.mk and Android.mk that MIchael recently
>> >>> >>>>> >>>> >> committed,
>> >>> >>>>> >>>> >> and
>> >>> >>>>> >>>> >> consequently removed the ones from Csound6's git repo.
>> >>> >>>>> >>>> >> This
>> >>> >>>>> >>>> >> means the
>> >>> >>>>> >>>> >> repo for fluidsynth-android will have the most up to
>> >>> >>>>> >>>> >> date
>> >>> >>>>> >>>> >> files.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>> >>> >>>>> >>>> >> downloadDependencies.sh now copies over the jni folder
>> >>> >>>>> >>>> >> from
>> >>> >>>>> >>>> >> plugins/patches/luajit-2.0 to the place where it checked
>> >>> >>>>> >>>> >> out
>> >>> >>>>> >>>> >> from GIT
>> >>> >>>>> >>>> >> for luajit.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> I did some further testing about plugins and I think at
>> >>> >>>>> >>>> >> this
>> >>> >>>>> >>>> >> point,
>> >>> >>>>> >>>> >> the crashing problem on my device is not with loading of
>> >>> >>>>> >>>> >> libs
>> >>> >>>>> >>>> >> but
>> >>> >>>>> >>>> >> specifically the Lua opcodes.  If I remove just that
>> >>> >>>>> >>>> >> library, I
>> >>> >>>>> >>>> >> can
>> >>> >>>>> >>>> >> load/reload/render multiple times without crashes.  I
>> >>> >>>>> >>>> >> believe
>> >>> >>>>> >>>> >> Andres
>> >>> >>>>> >>>> >> had posted an issue where the Lua opcodes was crashing
>> >>> >>>>> >>>> >> on
>> >>> >>>>> >>>> >> load
>> >>> >>>>> >>>> >> for his
>> >>> >>>>> >>>> >> system but that seems to be resolved for him.  I haven't
>> >>> >>>>> >>>> >> found
>> >>> >>>>> >>>> >> a good
>> >>> >>>>> >>>> >> way to debug this on Android (I haven't gotten ndk-gdb
>> >>> >>>>> >>>> >> to
>> >>> >>>>> >>>> >> connect).
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Thanks!
>> >>> >>>>> >>>> >> steven
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> ------------------------------------------------------------------------------
>> >>> >>>>> >>>> >> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Build for Windows Store.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> >> _______________________________________________
>> >>> >>>>> >>>> >> Csound-devel mailing list
>> >>> >>>>> >>>> >> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > ------------------------------------------------------------------------------
>> >>> >>>>> >>>> > This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > Build for Windows Store.
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> > _______________________________________________
>> >>> >>>>> >>>> > Csound-devel mailing list
>> >>> >>>>> >>>> > Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> ------------------------------------------------------------------------------
>> >>> >>>>> >>>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Build for Windows Store.
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> _______________________________________________
>> >>> >>>>> >>>> Csound-devel mailing list
>> >>> >>>>> >>>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> ------------------------------------------------------------------------------
>> >>> >>>>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>
>> >>> >>>>> >>> Build for Windows Store.
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>> >>> >>>>> >>> Csound-devel mailing list
>> >>> >>>>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> Dr Victor Lazzarini
>> >>> >>>>> >>> Senior Lecturer
>> >>> >>>>> >>> Dept. of Music
>> >>> >>>>> >>> NUI Maynooth Ireland
>> >>> >>>>> >>> tel.: +353 1 708 3545
>> >>> >>>>> >>> Victor dot Lazzarini AT nuim dot ie
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> ------------------------------------------------------------------------------
>> >>> >>>>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>
>> >>> >>>>> >>> Build for Windows Store.
>> >>> >>>>> >>>
>> >>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>> _______________________________________________
>> >>> >>>>> >>> Csound-devel mailing list
>> >>> >>>>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> ------------------------------------------------------------------------------
>> >>> >>>>> >> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>
>> >>> >>>>> >> Build for Windows Store.
>> >>> >>>>> >>
>> >>> >>>>> >> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >> _______________________________________________
>> >>> >>>>> >> Csound-devel mailing list
>> >>> >>>>> >> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> ------------------------------------------------------------------------------
>> >>> >>>>> This SF.net email is sponsored by Windows:
>> >>> >>>>>
>> >>> >>>>> Build for Windows Store.
>> >>> >>>>>
>> >>> >>>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> _______________________________________________
>> >>> >>>>> Csound-devel mailing list
>> >>> >>>>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> ------------------------------------------------------------------------------
>> >>> >>>> This SF.net email is sponsored by Windows:
>> >>> >>>>
>> >>> >>>> Build for Windows Store.
>> >>> >>>>
>> >>> >>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>> _______________________________________________
>> >>> >>>> Csound-devel mailing list
>> >>> >>>> Csound-devel@lists.sourceforge.net
>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> ------------------------------------------------------------------------------
>> >>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>
>> >>> >>> Build for Windows Store.
>> >>> >>>
>> >>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>> _______________________________________________
>> >>> >>> Csound-devel mailing list
>> >>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------------
>> >>> > This SF.net email is sponsored by Windows:
>> >>> >
>> >>> > Build for Windows Store.
>> >>> >
>> >>> > http://p.sf.net/sfu/windows-dev2dev
>> >>> > _______________________________________________
>> >>> > Csound-devel mailing list
>> >>> > Csound-devel@lists.sourceforge.net
>> >>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> This SF.net email is sponsored by Windows:
>> >>>
>> >>> Build for Windows Store.
>> >>>
>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by Windows:
>> >>
>> >> Build for Windows Store.
>> >>
>> >> http://p.sf.net/sfu/windows-dev2dev
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Right now, for some minutes, Csound6 git for the master branch is not accessible. Either it is busy, or it is messed up.

Regards,

Mike

===========================

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Mon, Jul 8, 2013 at 3:44 PM, Steven Yi <stevenyi@gmail.com> wrote:

Just a note, I realized I hadn't pushed the change (git was waiting
for me to enter password).  I just pushed the change now, thanks!

On Mon, Jul 8, 2013 at 3:34 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
> Erasing at end() would be a bug and should crash! If so mea culpa.
>
> My own workaround is simply to avoid calling atexit.
>
> I am investigating further. One this is for sure, process lifecycle and
> handling are VERY different on Android. In general, apps don't know whether
> they are alive or dead. The OS keeps pushing apps that the user doesn't
> interact with further into the grave. Generally, apps don't exit because the
> user did anything but because the OS kills them.
>
> POSIX also gives no precise guarantees about the order of things at exit.
>
> I would prefer to let the OS clean up unless we have locks that it can't
> unlock. I'll review your code re: memory leaks, but if this is at exit, not
> to worry.
>
> I will post a new build tonight.
>
> Regards,
> Mike
>
>
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Jul 8, 2013 at 2:04 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> Hi Michael,
>>
>> I've pushed a workaround fix.  I'm able to do multiple renders on
>> Android and no longer get a crash on Linux. I'm still not sure what
>> the root cause of the original problem is, but I suspect that once
>> atexit is called, somehow the static memory for the lua states is
>> wiped.  It's odd since we're in the same thread id, but that's as far
>> as I can imagine as a guess.  Anyways, the code does make more sense
>> to me that if it's == to end(), not to try to erase anyways.
>>
>> At least for now this prevents crashes. I can render multiple times
>> with Lua_ScoreGen and trapped on Android.  I have no idea if this
>> introduces a memory leak at all; maybe you can take a look as my C++
>> skills are not up to par to diagnose this.
>>
>> Otherwise, I'm at least glad that this is working.  I'd like to get
>> confirmation from Andres on Linux and would also like if you could
>> post a new Android build and we can get confirmation from others with
>> Android.  Seems though we're getting closer for a release. :)
>>
>> Thanks!
>> steven
>>
>> On Mon, Jul 8, 2013 at 1:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> > I tried with a fresh build from GIT.
>> >
>> > BTW: perhaps a hint, I put a breakpoint in the == function (line 122,
>> > LuaCsound.cpp).  When the manageLuaState with 'C' is called on LInux,
>> > this gets called from the STL find, and I get this:
>> >
>> > (gdb) print a.thread
>> > $17 = 6311936
>> > (gdb) print b.thread
>> > $18 = 140737353996128
>> >
>> > So the threads are no longer matching up by the time 'C' is called.
>> > During the initial 5 'O' calls, I get this:
>> >
>> > Breakpoint 3, operator== (a=..., b=...)
>> >     at /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:122
>> > 122    if (pthread_equal(a.thread, b.thread)) {
>> > (gdb) print a.thread
>> > $19 = 140737353996128
>> > (gdb) print b.thread
>> > $20 = 140737353996128
>> >
>> >
>> > Note, I'm pretty sure a in this case is the value held within the
>> > vector, as printing luaStateForThread.thread in the manageLuaState
>> > funciton shows the long thread id.
>> >
>> >
>> >
>> > On Mon, Jul 8, 2013 at 12:40 PM, Michael Gogins
>> > <michael.gogins@gmail.com> wrote:
>> >> Did you try from a fresh build or from a SourceForge app download? I
>> >> haven't
>> >> updated the latter with my fix yet.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >>
>> >> ===========================
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Mon, Jul 8, 2013 at 12:32 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> >>>
>> >>> Hi Michael,
>> >>>
>> >>> I just tried CSDPlayer and it's still crashing.  I imagine Linux will
>> >>> still crash since this change doesn't apply for it there.
>> >>>
>> >>> I wonder if there's some weird issue with how static is treated on
>> >>> *nix with gcc (which would apply to Linux and Android both). Seems
>> >>> like a longshot but I'm really not sure what's going on. :)   I'm
>> >>> catching up a bit today on things before heading back to unpacking,
>> >>> but will try to do some further gdb diagnosis on Linux.
>> >>>
>> >>> Thanks!
>> >>> steven
>> >>>
>> >>> On Sat, Jul 6, 2013 at 12:24 PM, Michael Gogins
>> >>> <michael.gogins@gmail.com> wrote:
>> >>> > I have pushed code to call csoundInitialize(CSOUNDINIT_NO_ATEXIT) in
>> >>> > CSDPlayer's static initialization block. As I understand it, this
>> >>> > function
>> >>> > only needs to be called once in process, is that correct?
>> >>> >
>> >>> > By the way, Steven, thanks for doing the patches directory.
>> >>> >
>> >>> > Regards,
>> >>> > Mike
>> >>> >
>> >>> >
>> >>> > ===========================
>> >>> > Michael Gogins
>> >>> > Irreducible Productions
>> >>> > http://michaelgogins.tumblr.com
>> >>> > Michael dot Gogins at gmail dot com
>> >>> >
>> >>> >
>> >>> > On Sat, Jul 6, 2013 at 11:44 AM, Michael Gogins
>> >>> > <michael.gogins@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> I changed the code some time ago so that this atexit stuff would
>> >>> >> not be
>> >>> >> called on WIndows, because it always caused a crash on exit and I
>> >>> >> had
>> >>> >> no
>> >>> >> idea how to fix it.
>> >>> >>
>> >>> >> On Android, the NDK docs advise allowing Android itself to do all
>> >>> >> cleanup
>> >>> >> on exit, so I will change the CsoundAndroid  or CSDPlayuer code,
>> >>> >> whichever
>> >>> >> is most appropraite, to pass the CSOUNDINIT_NO_ATEXIT flag to
>> >>> >> csoundInitialize. Or something to avoid the atexit stuff on
>> >>> >> Android.
>> >>> >>
>> >>> >> I don't know why I don't see this bug on the Galaxy S4.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Mike
>> >>> >>
>> >>> >>
>> >>> >> ===========================
>> >>> >> Michael Gogins
>> >>> >> Irreducible Productions
>> >>> >> http://michaelgogins.tumblr.com
>> >>> >> Michael dot Gogins at gmail dot com
>> >>> >>
>> >>> >>
>> >>> >> On Sat, Jul 6, 2013 at 10:49 AM, Andres Cabrera
>> >>> >> <mantaraya36@gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Yes, these are the issues I'm having. I think they don't occur on
>> >>> >>> windows
>> >>> >>> because there is no function registered with atexit (see
>> >>> >>> csoundInitialize),
>> >>> >>> but I'm not sure why it's not crashing on Os X.
>> >>> >>>
>> >>> >>> Cheers,
>> >>> >>> Andres
>> >>> >>>
>> >>> >>> On Jul 5, 2013 7:03 PM, "Michael Gogins"
>> >>> >>> <michael.gogins@gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> I'm happy to help, the information supplied will be helpful.
>> >>> >>>> Unfortunately, I don't get this crash here... but I can probably
>> >>> >>>> figure out
>> >>> >>>> what is going on. The module cleanup function is probably not
>> >>> >>>> being
>> >>> >>>> called.
>> >>> >>>> I'll see if there's a workaround or if it is being called at an
>> >>> >>>> inopportune
>> >>> >>>> time, or I'll just preallocate a fixed number of Lua states (one
>> >>> >>>> per
>> >>> >>>> Csound
>> >>> >>>> thread) and keep them around. Something.
>> >>> >>>>
>> >>> >>>> Regards,
>> >>> >>>> Mike
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> ===========================
>> >>> >>>> Michael Gogins
>> >>> >>>> Irreducible Productions
>> >>> >>>> http://michaelgogins.tumblr.com
>> >>> >>>> Michael dot Gogins at gmail dot com
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Fri, Jul 5, 2013 at 9:38 PM, Steven Yi <stevenyi@gmail.com>
>> >>> >>>> wrote:
>> >>> >>>>>
>> >>> >>>>> Just some follow up, I had put a breakpoint on manageLuaState.
>> >>> >>>>> Using
>> >>> >>>>> testCsoundOrcSemantics, I saw five calls with "O" during the
>> >>> >>>>> tests,
>> >>> >>>>> then ctest printed its report, then with the call to
>> >>> >>>>> manageLuaState
>> >>> >>>>> with "C", I get the crash with the call to erase.
>> >>> >>>>>
>> >>> >>>>> I'm not used to debugging C++, but what I'm seeing is that the
>> >>> >>>>> iterator it during the "O" calls is:
>> >>> >>>>>
>> >>> >>>>> {_M_current = 0x6f3370}
>> >>> >>>>>
>> >>> >>>>> but on the "C" call I see:
>> >>> >>>>>
>> >>> >>>>> {_M_current = 0x6f3380}
>> >>> >>>>>
>> >>> >>>>> which is equal to the luaStatesForThreads.end().
>> >>> >>>>>
>> >>> >>>>> So... I'm not sure what's going on.  Perhaps Michael could help
>> >>> >>>>> debug/test.  I also don't know if this is the cause of the issue
>> >>> >>>>> on
>> >>> >>>>> Android as I haven't been able to really get gdb going there.
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> On Fri, Jul 5, 2013 at 8:56 PM, Steven Yi <stevenyi@gmail.com>
>> >>> >>>>> wrote:
>> >>> >>>>> > I ran "make test" on a Debian system and I get 3 failures.
>> >>> >>>>> > CTest
>> >>> >>>>> > reports 2 of them are failed tests and one is a segfault. I
>> >>> >>>>> > ran
>> >>> >>>>> > the
>> >>> >>>>> > failed tests with gdb and got:
>> >>> >>>>> >
>> >>> >>>>> > with testCsoundTypeSystem:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff702b806 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff702b806 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>> >>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread>
>> >>> >>>>> > (
>> >>> >>>>> >     __first=0x6f01f0, __last=0x6f01e0, __result=0x6f01e0) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>> >>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>> >>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f01f0,
>> >>> >>>>> >     __last=0x6f01e0, __result=0x6f01e0) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>> >>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...)
>> >>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>> >>> >>>>> > #4  0x00007ffff52af4af in
>> >>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>> >>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >::erase
>> >>> >>>>> > (this=0x7ffff54b67a0,
>> >>> >>>>> >     __position=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/vector.tcc:139
>> >>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>> >>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy
>> >>> >>>>> > (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>> >>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules
>> >>> >>>>> > (csound=0x6fa860)
>> >>> >>>>> > at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>> >>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>> >>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x6fa860) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>> >>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>> >>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #15 0x0000000000400bf9 in _start ()
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > with testCsoundOrcSemantics:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff702b7fc in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff702b7fc in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #1  0x00007ffff52b2286 in std::__copy_move<false, true,
>> >>> >>>>> > std::random_access_iterator_tag>::__copy_m<LuaStateForThread>
>> >>> >>>>> > (
>> >>> >>>>> >     __first=0x6f3390, __last=0x6f3380, __result=0x6f3380) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:366
>> >>> >>>>> > #2  0x00007ffff52b199e in std::__copy_move_a<false,
>> >>> >>>>> > LuaStateForThread*, LuaStateForThread*> (__first=0x6f3390,
>> >>> >>>>> >     __last=0x6f3380, __result=0x6f3380) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:384
>> >>> >>>>> > #3  0x00007ffff52b07b3 in std::__copy_move_a2<false,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...)
>> >>> >>>>> >     at /usr/include/c++/4.7/bits/stl_algobase.h:422
>> >>> >>>>> > #4  0x00007ffff52af4af in
>> >>> >>>>> > std::copy<__gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >,
>> >>> >>>>> > __gnu_cxx::__normal_iterator<LuaStateForThread*,
>> >>> >>>>> > std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >
>> >>> >>>>> > >
>> >>> >>>>> > >
>> >>> >>>>> > (__first=..., __last=..., __result=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/stl_algobase.h:454
>> >>> >>>>> > #5  0x00007ffff52ae436 in std::vector<LuaStateForThread,
>> >>> >>>>> > std::allocator<LuaStateForThread> >::erase
>> >>> >>>>> > (this=0x7ffff54b67a0,
>> >>> >>>>> >     __position=...) at
>> >>> >>>>> > /usr/include/c++/4.7/bits/vector.tcc:139
>> >>> >>>>> > #6  0x00007ffff52ac9c3 in manageLuaState (operation=67 'C') at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:168
>> >>> >>>>> > #7  0x00007ffff52acb39 in csoundModuleDestroy
>> >>> >>>>> > (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Opcodes/LuaCsound.cpp:738
>> >>> >>>>> > #8  0x00007ffff7a66f92 in csoundDestroyModules
>> >>> >>>>> > (csound=0x960f90)
>> >>> >>>>> > at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csmodule.c:637
>> >>> >>>>> > #9  0x00007ffff7a6afd7 in reset (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:2616
>> >>> >>>>> > #10 0x00007ffff7a67ab8 in csoundDestroy (csound=0x960f90) at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:1190
>> >>> >>>>> > #11 0x00007ffff7a67747 in destroy_all_instances () at
>> >>> >>>>> > /home/steven/csound/csound6/Top/csound.c:888
>> >>> >>>>> > #12 0x00007ffff6f3adf2 in ?? () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #13 0x00007ffff6f3ae45 in exit () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #14 0x00007ffff6f22eb4 in __libc_start_main () from
>> >>> >>>>> > /lib/x86_64-linux-gnu/libc.so.6
>> >>> >>>>> > #15 0x0000000000400c39 in _start ()
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > with testCircularBuffer:
>> >>> >>>>> >
>> >>> >>>>> > Program received signal SIGSEGV, Segmentation fault.
>> >>> >>>>> > 0x00007ffff793d9b0 in csoundReadCircularBuffer
>> >>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>> >>> >>>>> > out=0x7fffffffd960,
>> >>> >>>>> >     items=16) at
>> >>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>> >>> >>>>> > 67        int itemsread, numelem = ((circular_buffer
>> >>> >>>>> > *)p)->numelem;
>> >>> >>>>> > (gdb) bt
>> >>> >>>>> > #0  0x00007ffff793d9b0 in csoundReadCircularBuffer
>> >>> >>>>> > (csound=0x4383800043830000, p=0x4382800043820000,
>> >>> >>>>> > out=0x7fffffffd960,
>> >>> >>>>> >     items=16) at
>> >>> >>>>> > /home/steven/csound/csound6/InOut/circularbuffer.c:67
>> >>> >>>>> > #1  0x0000000000400fca in test_read_write_diff_size ()
>> >>> >>>>> >     at
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:64
>> >>> >>>>> > #2  0x00007ffff76bafe9 in ?? () from /usr/lib/libcunit.so.1
>> >>> >>>>> > #3  0x00007ffff76bb3c7 in ?? () from /usr/lib/libcunit.so.1
>> >>> >>>>> > #4  0x00007ffff76bb6e8 in CU_run_all_tests () from
>> >>> >>>>> > /usr/lib/libcunit.so.1
>> >>> >>>>> > #5  0x0000000000401673 in main () at
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > /home/steven/csound/csound6/tests/c/csound_circular_buffer_test.c:164
>> >>> >>>>> >
>> >>> >>>>> > On Fri, Jul 5, 2013 at 6:39 PM, Andres Cabrera
>> >>> >>>>> > <mantaraya36@gmail.com> wrote:
>> >>> >>>>> >> But then you don't have the Lua opcodes...
>> >>> >>>>> >>
>> >>> >>>>> >> I'll look again at the signal flow opcodes to see if it's a
>> >>> >>>>> >> problem
>> >>> >>>>> >> on my
>> >>> >>>>> >> end.
>> >>> >>>>> >>
>> >>> >>>>> >> Cheers,
>> >>> >>>>> >> Andrés
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> On Fri, Jul 5, 2013 at 2:22 PM, Victor Lazzarini
>> >>> >>>>> >> <Victor.Lazzarini@nuim.ie>
>> >>> >>>>> >> wrote:
>> >>> >>>>> >>>
>> >>> >>>>> >>> I just ran the testCsoundTypeSystem here, it appears to pass
>> >>> >>>>> >>> alright:
>> >>> >>>>> >>>
>> >>> >>>>> >>> coltrane:c victor$ ./testCsoundTypeSystem
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>      CUnit - A unit testing framework for C - Version 2.1-2
>> >>> >>>>> >>>      http://cunit.sourceforge.net/
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> Suite: Type System Tests
>> >>> >>>>> >>>   Test: Test Type System ...virtual_keyboard real time MIDI
>> >>> >>>>> >>> plugin
>> >>> >>>>> >>> for
>> >>> >>>>> >>> Csound
>> >>> >>>>> >>> 0dBFS level = 32768.0
>> >>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>> >>> >>>>> >>> libsndfile-1.0.21
>> >>> >>>>> >>> passed
>> >>> >>>>> >>>   Test: Test getVarSimpleName ...virtual_keyboard real time
>> >>> >>>>> >>> MIDI
>> >>> >>>>> >>> plugin
>> >>> >>>>> >>> for Csound
>> >>> >>>>> >>> 0dBFS level = 32768.0
>> >>> >>>>> >>> Csound version 6.00 (double samples) Jul  4 2013
>> >>> >>>>> >>> libsndfile-1.0.21
>> >>> >>>>> >>> passed
>> >>> >>>>> >>>
>> >>> >>>>> >>> Run Summary:    Type  Total    Ran Passed Failed Inactive
>> >>> >>>>> >>>               suites      1      1    n/a      0        0
>> >>> >>>>> >>>                tests      2      2      2      0        0
>> >>> >>>>> >>>              asserts      9      9      9      0      n/a
>> >>> >>>>> >>>
>> >>> >>>>> >>> Elapsed time =    0.061 seconds
>> >>> >>>>> >>> end of score.   overall amps:      0.0
>> >>> >>>>> >>>   overall samples out of range:        0
>> >>> >>>>> >>> 0 errors in performance
>> >>> >>>>> >>> Elapsed time at end of performance: real: 0.251s, CPU:
>> >>> >>>>> >>> 0.001s
>> >>> >>>>> >>> end of score.   overall amps:      0.0
>> >>> >>>>> >>>   overall samples out of range:        0
>> >>> >>>>> >>> 0 errors in performance
>> >>> >>>>> >>> Elapsed time at end of performance: real: 0.316s, CPU:
>> >>> >>>>> >>> 0.020s
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> On 5 Jul 2013, at 21:58, Andres Cabrera wrote:
>> >>> >>>>> >>>
>> >>> >>>>> >>> You can use the test programs to check:
>> >>> >>>>> >>> testChannels will run fine, but testCsoundTypeSystem will
>> >>> >>>>> >>> fail.
>> >>> >>>>> >>>
>> >>> >>>>> >>> Cheers,
>> >>> >>>>> >>> Andrés
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> On Fri, Jul 5, 2013 at 1:53 PM, Steven Yi
>> >>> >>>>> >>> <stevenyi@gmail.com>
>> >>> >>>>> >>> wrote:
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Hi Andres,
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Thanks for following up on that.  Yes, I think we need to
>> >>> >>>>> >>>> ensure
>> >>> >>>>> >>>> that
>> >>> >>>>> >>>> these are not going to crash on multiple renders.  Do you
>> >>> >>>>> >>>> or
>> >>> >>>>> >>>> anyone
>> >>> >>>>> >>>> else have time to write a quick .c program that will render
>> >>> >>>>> >>>> a
>> >>> >>>>> >>>> csd
>> >>> >>>>> >>>> multiple times so that we can reproduce the crash and trace
>> >>> >>>>> >>>> with
>> >>> >>>>> >>>> GDB
>> >>> >>>>> >>>> easily?  (I need to look at other things for the next bit
>> >>> >>>>> >>>> of my
>> >>> >>>>> >>>> work
>> >>> >>>>> >>>> time, but can help debug/test later)
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Thanks!
>> >>> >>>>> >>>> steven
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> On Fri, Jul 5, 2013 at 4:50 PM, Andres Cabrera
>> >>> >>>>> >>>> <mantaraya36@gmail.com>
>> >>> >>>>> >>>> wrote:
>> >>> >>>>> >>>> > Hi Steven,
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > It was solved for me by removing libLuaOpcodes... :P
>> >>> >>>>> >>>> > BTW, I'm having a similar issue with libsignalflow
>> >>> >>>>> >>>> > opcodes,
>> >>> >>>>> >>>> > so
>> >>> >>>>> >>>> > I've had
>> >>> >>>>> >>>> > to
>> >>> >>>>> >>>> > take those out as well. They seem not to be cleaning up
>> >>> >>>>> >>>> > correctly. I
>> >>> >>>>> >>>> > think
>> >>> >>>>> >>>> > it's important to fix these before release or not include
>> >>> >>>>> >>>> > them
>> >>> >>>>> >>>> > in
>> >>> >>>>> >>>> > installers
>> >>> >>>>> >>>> > as they will crash all hosts that do more than one run.
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > Cheers,
>> >>> >>>>> >>>> > Andrés
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > On Fri, Jul 5, 2013 at 1:39 PM, Steven Yi
>> >>> >>>>> >>>> > <stevenyi@gmail.com>
>> >>> >>>>> >>>> > wrote:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Hi All,
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> I've taken a look at the changes from Michael. For
>> >>> >>>>> >>>> >> Android,
>> >>> >>>>> >>>> >> to
>> >>> >>>>> >>>> >> get
>> >>> >>>>> >>>> >> things working to use downloadDependencies.sh and
>> >>> >>>>> >>>> >> build-all.sh,
>> >>> >>>>> >>>> >> I made
>> >>> >>>>> >>>> >> the following modifications:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> 1. I updated the fluidsynth-android Bitbucket repository
>> >>> >>>>> >>>> >> with
>> >>> >>>>> >>>> >> the
>> >>> >>>>> >>>> >> Application.mk and Android.mk that MIchael recently
>> >>> >>>>> >>>> >> committed,
>> >>> >>>>> >>>> >> and
>> >>> >>>>> >>>> >> consequently removed the ones from Csound6's git repo.
>> >>> >>>>> >>>> >> This
>> >>> >>>>> >>>> >> means the
>> >>> >>>>> >>>> >> repo for fluidsynth-android will have the most up to
>> >>> >>>>> >>>> >> date
>> >>> >>>>> >>>> >> files.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> 2. I moved luajit-2.0 from plugins to plugins/patches.
>> >>> >>>>> >>>> >> downloadDependencies.sh now copies over the jni folder
>> >>> >>>>> >>>> >> from
>> >>> >>>>> >>>> >> plugins/patches/luajit-2.0 to the place where it checked
>> >>> >>>>> >>>> >> out
>> >>> >>>>> >>>> >> from GIT
>> >>> >>>>> >>>> >> for luajit.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> I did some further testing about plugins and I think at
>> >>> >>>>> >>>> >> this
>> >>> >>>>> >>>> >> point,
>> >>> >>>>> >>>> >> the crashing problem on my device is not with loading of
>> >>> >>>>> >>>> >> libs
>> >>> >>>>> >>>> >> but
>> >>> >>>>> >>>> >> specifically the Lua opcodes.  If I remove just that
>> >>> >>>>> >>>> >> library, I
>> >>> >>>>> >>>> >> can
>> >>> >>>>> >>>> >> load/reload/render multiple times without crashes.  I
>> >>> >>>>> >>>> >> believe
>> >>> >>>>> >>>> >> Andres
>> >>> >>>>> >>>> >> had posted an issue where the Lua opcodes was crashing
>> >>> >>>>> >>>> >> on
>> >>> >>>>> >>>> >> load
>> >>> >>>>> >>>> >> for his
>> >>> >>>>> >>>> >> system but that seems to be resolved for him.  I haven't
>> >>> >>>>> >>>> >> found
>> >>> >>>>> >>>> >> a good
>> >>> >>>>> >>>> >> way to debug this on Android (I haven't gotten ndk-gdb
>> >>> >>>>> >>>> >> to
>> >>> >>>>> >>>> >> connect).
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Thanks!
>> >>> >>>>> >>>> >> steven
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> ------------------------------------------------------------------------------
>> >>> >>>>> >>>> >> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> Build for Windows Store.
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> >> _______________________________________________
>> >>> >>>>> >>>> >> Csound-devel mailing list
>> >>> >>>>> >>>> >> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> >>
>> >>> >>>>> >>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > ------------------------------------------------------------------------------
>> >>> >>>>> >>>> > This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > Build for Windows Store.
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>> > http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> > _______________________________________________
>> >>> >>>>> >>>> > Csound-devel mailing list
>> >>> >>>>> >>>> > Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>> >
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> ------------------------------------------------------------------------------
>> >>> >>>>> >>>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> Build for Windows Store.
>> >>> >>>>> >>>>
>> >>> >>>>> >>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>>> _______________________________________________
>> >>> >>>>> >>>> Csound-devel mailing list
>> >>> >>>>> >>>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> ------------------------------------------------------------------------------
>> >>> >>>>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>
>> >>> >>>>> >>> Build for Windows Store.
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
>> >>> >>>>> >>> Csound-devel mailing list
>> >>> >>>>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> Dr Victor Lazzarini
>> >>> >>>>> >>> Senior Lecturer
>> >>> >>>>> >>> Dept. of Music
>> >>> >>>>> >>> NUI Maynooth Ireland
>> >>> >>>>> >>> tel.: +353 1 708 3545
>> >>> >>>>> >>> Victor dot Lazzarini AT nuim dot ie
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>>
>> >>> >>>>> >>> ------------------------------------------------------------------------------
>> >>> >>>>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>>
>> >>> >>>>> >>> Build for Windows Store.
>> >>> >>>>> >>>
>> >>> >>>>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >>> _______________________________________________
>> >>> >>>>> >>> Csound-devel mailing list
>> >>> >>>>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> ------------------------------------------------------------------------------
>> >>> >>>>> >> This SF.net email is sponsored by Windows:
>> >>> >>>>> >>
>> >>> >>>>> >> Build for Windows Store.
>> >>> >>>>> >>
>> >>> >>>>> >> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> >> _______________________________________________
>> >>> >>>>> >> Csound-devel mailing list
>> >>> >>>>> >> Csound-devel@lists.sourceforge.net
>> >>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>> >>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> ------------------------------------------------------------------------------
>> >>> >>>>> This SF.net email is sponsored by Windows:
>> >>> >>>>>
>> >>> >>>>> Build for Windows Store.
>> >>> >>>>>
>> >>> >>>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>>> _______________________________________________
>> >>> >>>>> Csound-devel mailing list
>> >>> >>>>> Csound-devel@lists.sourceforge.net
>> >>> >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> ------------------------------------------------------------------------------
>> >>> >>>> This SF.net email is sponsored by Windows:
>> >>> >>>>
>> >>> >>>> Build for Windows Store.
>> >>> >>>>
>> >>> >>>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>>> _______________________________________________
>> >>> >>>> Csound-devel mailing list
>> >>> >>>> Csound-devel@lists.sourceforge.net
>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> ------------------------------------------------------------------------------
>> >>> >>> This SF.net email is sponsored by Windows:
>> >>> >>>
>> >>> >>> Build for Windows Store.
>> >>> >>>
>> >>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> >>> _______________________________________________
>> >>> >>> Csound-devel mailing list
>> >>> >>> Csound-devel@lists.sourceforge.net
>> >>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------------
>> >>> > This SF.net email is sponsored by Windows:
>> >>> >
>> >>> > Build for Windows Store.
>> >>> >
>> >>> > http://p.sf.net/sfu/windows-dev2dev
>> >>> > _______________________________________________
>> >>> > Csound-devel mailing list
>> >>> > Csound-devel@lists.sourceforge.net
>> >>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> This SF.net email is sponsored by Windows:
>> >>>
>> >>> Build for Windows Store.
>> >>>
>> >>> http://p.sf.net/sfu/windows-dev2dev
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by Windows:
>> >>
>> >> Build for Windows Store.
>> >>
>> >> http://p.sf.net/sfu/windows-dev2dev
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel