Csound Csound-dev Csound-tekno Search About

[Cs-dev] Csound crashing

Date2014-07-18 02:43
FromMichael Gogins
Subject[Cs-dev] Csound crashing
AttachmentsNone  None  
On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model and dw2 exception handling, Csound now always crashes with the following stack trace.

I suspect that the size of some element in the CSOUND struct, possibly the pthread_t objects which have been a source of trouble in the past, are now declared inconsistently.

What has changed?

[New Thread 68.0x660]
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
Csound version 6.03.2 (double samples) Jul 17 2014
libsndfile-1.0.25
UnifiedCSD:  ..\examples\trapped.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
rtaudio: PortAudio module enabled ...
using callback interface
rtmidi: PortMIDI module enabled
memory allocate failure for 12
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance
Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
warning: HEAP[csound.exe]:
warning: Heap block at 025767C8 modified at 025767E4 past requested size of 14


Program received signal SIGTRAP, Trace/breakpoint trap.
0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x025767c8 in ?? ()
#3  0x775919ff in ntdll!RtlCreateUserThread ()
   from C:\Windows\SYSTEM32\ntdll.dll
#4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x77588973 in ntdll!RtlCreateUserThread ()
   from C:\Windows\SYSTEM32\ntdll.dll
#6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
   from C:\Windows\SYSTEM32\ntdll.dll
#7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
#8  0x005b0000 in ?? ()
#9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
    at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
#10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
    at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
#11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
    at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
#12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
    at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
(gdb)

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
Date2014-07-18 04:34
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
I wonder if it is one of two things I worked on: one was changing the
allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
using a new macro.  The error would seem to point to one of those two
changes causing an issue.

Last time something like this happened, where there was a
memory-related crash only on windows, I seem to remember an alignment
issue. The error message is a bit ambiguous about the allocation of
size 12 (that would be the size of a CS_VAR_MEM though...).

I've written a note to take a look at this in the morning.

Thanks!
steven

On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
 wrote:
> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
> and dw2 exception handling, Csound now always crashes with the following
> stack trace.
>
> I suspect that the size of some element in the CSOUND struct, possibly the
> pthread_t objects which have been a source of trouble in the past, are now
> declared inconsistently.
>
> What has changed?
>
> [New Thread 68.0x660]
> virtual_keyboard real time MIDI plugin for Csound
> 0dBFS level = 32768.0
> Csound version 6.03.2 (double samples) Jul 17 2014
> libsndfile-1.0.25
> UnifiedCSD:  ..\examples\trapped.csd
> STARTING FILE
> Creating options
> Creating orchestra
> Creating score
> rtaudio: PortAudio module enabled ...
> using callback interface
> rtmidi: PortMIDI module enabled
> memory allocate failure for 12
> end of score.              overall amps:      0.0      0.0
>            overall samples out of range:        0        0
> 0 errors in performance
> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
> warning: HEAP[csound.exe]:
> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
> 14
>
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> (gdb) bt
> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
> #2  0x025767c8 in ?? ()
> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
> #8  0x005b0000 in ?? ()
> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>     at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>     at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>     at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>     at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
> (gdb)
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-18 10:42
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
I think there might be some issue in this new code, because the Android code is also crashing:

07-18 10:40:59.526: D/CsoundObj(623): Creating score
07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc

I’ll revert locally and test again.

Victor
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 18 Jul 2014, at 04:34, Steven Yi  wrote:

> I wonder if it is one of two things I worked on: one was changing the
> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
> using a new macro.  The error would seem to point to one of those two
> changes causing an issue.
> 
> Last time something like this happened, where there was a
> memory-related crash only on windows, I seem to remember an alignment
> issue. The error message is a bit ambiguous about the allocation of
> size 12 (that would be the size of a CS_VAR_MEM though...).
> 
> I've written a note to take a look at this in the morning.
> 
> Thanks!
> steven
> 
> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>  wrote:
>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>> and dw2 exception handling, Csound now always crashes with the following
>> stack trace.
>> 
>> I suspect that the size of some element in the CSOUND struct, possibly the
>> pthread_t objects which have been a source of trouble in the past, are now
>> declared inconsistently.
>> 
>> What has changed?
>> 
>> [New Thread 68.0x660]
>> virtual_keyboard real time MIDI plugin for Csound
>> 0dBFS level = 32768.0
>> Csound version 6.03.2 (double samples) Jul 17 2014
>> libsndfile-1.0.25
>> UnifiedCSD:  ..\examples\trapped.csd
>> STARTING FILE
>> Creating options
>> Creating orchestra
>> Creating score
>> rtaudio: PortAudio module enabled ...
>> using callback interface
>> rtmidi: PortMIDI module enabled
>> memory allocate failure for 12
>> end of score.              overall amps:      0.0      0.0
>>           overall samples out of range:        0        0
>> 0 errors in performance
>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>> warning: HEAP[csound.exe]:
>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>> 14
>> 
>> 
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> (gdb) bt
>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>> #2  0x025767c8 in ?? ()
>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>> #8  0x005b0000 in ?? ()
>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>    at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>    at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>    at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>    at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>> (gdb)
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-18 10:57
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
yes, I reverted to before the branch merge and the android examples are working again.
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:

> I think there might be some issue in this new code, because the Android code is also crashing:
> 
> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
> 
> I’ll revert locally and test again.
> 
> Victor
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
> 
>> I wonder if it is one of two things I worked on: one was changing the
>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>> using a new macro.  The error would seem to point to one of those two
>> changes causing an issue.
>> 
>> Last time something like this happened, where there was a
>> memory-related crash only on windows, I seem to remember an alignment
>> issue. The error message is a bit ambiguous about the allocation of
>> size 12 (that would be the size of a CS_VAR_MEM though...).
>> 
>> I've written a note to take a look at this in the morning.
>> 
>> Thanks!
>> steven
>> 
>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>  wrote:
>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>> and dw2 exception handling, Csound now always crashes with the following
>>> stack trace.
>>> 
>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>> pthread_t objects which have been a source of trouble in the past, are now
>>> declared inconsistently.
>>> 
>>> What has changed?
>>> 
>>> [New Thread 68.0x660]
>>> virtual_keyboard real time MIDI plugin for Csound
>>> 0dBFS level = 32768.0
>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>> libsndfile-1.0.25
>>> UnifiedCSD:  ..\examples\trapped.csd
>>> STARTING FILE
>>> Creating options
>>> Creating orchestra
>>> Creating score
>>> rtaudio: PortAudio module enabled ...
>>> using callback interface
>>> rtmidi: PortMIDI module enabled
>>> memory allocate failure for 12
>>> end of score.              overall amps:      0.0      0.0
>>>          overall samples out of range:        0        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>> warning: HEAP[csound.exe]:
>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>> 14
>>> 
>>> 
>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> (gdb) bt
>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>> #2  0x025767c8 in ?? ()
>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>> #8  0x005b0000 in ?? ()
>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>   at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>   at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>> (gdb)
>>> 
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-18 13:34
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Hi Victor,

Thanks for testing and confirming that.  I'll do some investigation
first on Windows as I can use gdb easily there, and will look to test
any fixes on Android before committing.

Thanks!
steven

On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
 wrote:
> yes, I reverted to before the branch merge and the android examples are working again.
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>
>> I think there might be some issue in this new code, because the Android code is also crashing:
>>
>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>
>> I’ll revert locally and test again.
>>
>> Victor
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>>
>>
>>
>>
>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>
>>> I wonder if it is one of two things I worked on: one was changing the
>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>> using a new macro.  The error would seem to point to one of those two
>>> changes causing an issue.
>>>
>>> Last time something like this happened, where there was a
>>> memory-related crash only on windows, I seem to remember an alignment
>>> issue. The error message is a bit ambiguous about the allocation of
>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>
>>> I've written a note to take a look at this in the morning.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>  wrote:
>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>> and dw2 exception handling, Csound now always crashes with the following
>>>> stack trace.
>>>>
>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>> declared inconsistently.
>>>>
>>>> What has changed?
>>>>
>>>> [New Thread 68.0x660]
>>>> virtual_keyboard real time MIDI plugin for Csound
>>>> 0dBFS level = 32768.0
>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>> libsndfile-1.0.25
>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>> STARTING FILE
>>>> Creating options
>>>> Creating orchestra
>>>> Creating score
>>>> rtaudio: PortAudio module enabled ...
>>>> using callback interface
>>>> rtmidi: PortMIDI module enabled
>>>> memory allocate failure for 12
>>>> end of score.              overall amps:      0.0      0.0
>>>>          overall samples out of range:        0        0
>>>> 0 errors in performance
>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>> warning: HEAP[csound.exe]:
>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>> 14
>>>>
>>>>
>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> (gdb) bt
>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>> #2  0x025767c8 in ?? ()
>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>> #8  0x005b0000 in ?? ()
>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>   at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>   at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>> (gdb)
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/l
Date2014-07-18 16:05
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Just a side note, I just made a commit that got things working on
Windows (some bad pointer arithmetic). However, I just tried it on OSX
and am now getting crashes there. Hopefully should go a little quicker
as it's a little easier for me to debug on OSX. I'll update here as
soon as I get something fully working.

On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
> Hi Victor,
>
> Thanks for testing and confirming that.  I'll do some investigation
> first on Windows as I can use gdb easily there, and will look to test
> any fixes on Android before committing.
>
> Thanks!
> steven
>
> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>  wrote:
>> yes, I reverted to before the branch merge and the android examples are working again.
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>>
>>
>>
>>
>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>
>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>
>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>
>>> I’ll revert locally and test again.
>>>
>>> Victor
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>
>>>> I wonder if it is one of two things I worked on: one was changing the
>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>> using a new macro.  The error would seem to point to one of those two
>>>> changes causing an issue.
>>>>
>>>> Last time something like this happened, where there was a
>>>> memory-related crash only on windows, I seem to remember an alignment
>>>> issue. The error message is a bit ambiguous about the allocation of
>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>
>>>> I've written a note to take a look at this in the morning.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>  wrote:
>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>> stack trace.
>>>>>
>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>> declared inconsistently.
>>>>>
>>>>> What has changed?
>>>>>
>>>>> [New Thread 68.0x660]
>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>> 0dBFS level = 32768.0
>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>> libsndfile-1.0.25
>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>> STARTING FILE
>>>>> Creating options
>>>>> Creating orchestra
>>>>> Creating score
>>>>> rtaudio: PortAudio module enabled ...
>>>>> using callback interface
>>>>> rtmidi: PortMIDI module enabled
>>>>> memory allocate failure for 12
>>>>> end of score.              overall amps:      0.0      0.0
>>>>>          overall samples out of range:        0        0
>>>>> 0 errors in performance
>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>> warning: HEAP[csound.exe]:
>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>> 14
>>>>>
>>>>>
>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> (gdb) bt
>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #2  0x025767c8 in ?? ()
>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>> #8  0x005b0000 in ?? ()
>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>   at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>   at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>> (gdb)
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/list
Date2014-07-18 17:08
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
And another note, OSX is working, but Windows is not again.  I'm
digging into this but I have to step away for a bit, and will resume
when I get back later today.

On Fri, Jul 18, 2014 at 11:05 AM, Steven Yi  wrote:
> Just a side note, I just made a commit that got things working on
> Windows (some bad pointer arithmetic). However, I just tried it on OSX
> and am now getting crashes there. Hopefully should go a little quicker
> as it's a little easier for me to debug on OSX. I'll update here as
> soon as I get something fully working.
>
> On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
>> Hi Victor,
>>
>> Thanks for testing and confirming that.  I'll do some investigation
>> first on Windows as I can use gdb easily there, and will look to test
>> any fixes on Android before committing.
>>
>> Thanks!
>> steven
>>
>> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>>  wrote:
>>> yes, I reverted to before the branch merge and the android examples are working again.
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>>
>>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>>
>>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>>
>>>> I’ll revert locally and test again.
>>>>
>>>> Victor
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>>
>>>>> I wonder if it is one of two things I worked on: one was changing the
>>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>>> using a new macro.  The error would seem to point to one of those two
>>>>> changes causing an issue.
>>>>>
>>>>> Last time something like this happened, where there was a
>>>>> memory-related crash only on windows, I seem to remember an alignment
>>>>> issue. The error message is a bit ambiguous about the allocation of
>>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>>
>>>>> I've written a note to take a look at this in the morning.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>>  wrote:
>>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>>> stack trace.
>>>>>>
>>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>>> declared inconsistently.
>>>>>>
>>>>>> What has changed?
>>>>>>
>>>>>> [New Thread 68.0x660]
>>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>>> 0dBFS level = 32768.0
>>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>>> libsndfile-1.0.25
>>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>>> STARTING FILE
>>>>>> Creating options
>>>>>> Creating orchestra
>>>>>> Creating score
>>>>>> rtaudio: PortAudio module enabled ...
>>>>>> using callback interface
>>>>>> rtmidi: PortMIDI module enabled
>>>>>> memory allocate failure for 12
>>>>>> end of score.              overall amps:      0.0      0.0
>>>>>>          overall samples out of range:        0        0
>>>>>> 0 errors in performance
>>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>>> warning: HEAP[csound.exe]:
>>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>>> 14
>>>>>>
>>>>>>
>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> (gdb) bt
>>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #2  0x025767c8 in ?? ()
>>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>>> #8  0x005b0000 in ?? ()
>>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>>   at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>>   at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>>> (gdb)
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://list
Date2014-07-19 00:15
FromVictor Lazzarini
Subject[Cs-dev] android out channels (chnset) (was Re: Csound crashing)
Another problem (maybe unrelated), chnset on android is broken. I tested it by adding the line

chnset p5*(1+ksl), "freq"

to test.csd (simple test app). And this to the java side

public void updateValuesFromCsound() {
				// TODO Auto-generated method stub
				float f =  csoundObj.getCsound().GetChannel("freq");
				Log.d("CsoundAndroidActivity", "freq: " + f);	
			}

Instead of getting correct values in the range  440-880, I am getting values such as

07-19 00:10:21.490: D/CsoundAndroidActivity(672): freq: -1.5881865E-23

this does not seem to happen on the desktop, so I am wondering what the problem is. Any ideas
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 18 Jul 2014, at 17:08, Steven Yi  wrote:

> And another note, OSX is working, but Windows is not again.  I'm
> digging into this but I have to step away for a bit, and will resume
> when I get back later today.
> 
> On Fri, Jul 18, 2014 at 11:05 AM, Steven Yi  wrote:
>> Just a side note, I just made a commit that got things working on
>> Windows (some bad pointer arithmetic). However, I just tried it on OSX
>> and am now getting crashes there. Hopefully should go a little quicker
>> as it's a little easier for me to debug on OSX. I'll update here as
>> soon as I get something fully working.
>> 
>> On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
>>> Hi Victor,
>>> 
>>> Thanks for testing and confirming that.  I'll do some investigation
>>> first on Windows as I can use gdb easily there, and will look to test
>>> any fixes on Android before committing.
>>> 
>>> Thanks!
>>> steven
>>> 
>>> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>>>  wrote:
>>>> yes, I reverted to before the branch merge and the android examples are working again.
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>>> 
>>>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>>> 
>>>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>>> 
>>>>> I’ll revert locally and test again.
>>>>> 
>>>>> Victor
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>>> 
>>>>>> I wonder if it is one of two things I worked on: one was changing the
>>>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>>>> using a new macro.  The error would seem to point to one of those two
>>>>>> changes causing an issue.
>>>>>> 
>>>>>> Last time something like this happened, where there was a
>>>>>> memory-related crash only on windows, I seem to remember an alignment
>>>>>> issue. The error message is a bit ambiguous about the allocation of
>>>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>>> 
>>>>>> I've written a note to take a look at this in the morning.
>>>>>> 
>>>>>> Thanks!
>>>>>> steven
>>>>>> 
>>>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>>>> stack trace.
>>>>>>> 
>>>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>>>> declared inconsistently.
>>>>>>> 
>>>>>>> What has changed?
>>>>>>> 
>>>>>>> [New Thread 68.0x660]
>>>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>>>> 0dBFS level = 32768.0
>>>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>>>> libsndfile-1.0.25
>>>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>>>> STARTING FILE
>>>>>>> Creating options
>>>>>>> Creating orchestra
>>>>>>> Creating score
>>>>>>> rtaudio: PortAudio module enabled ...
>>>>>>> using callback interface
>>>>>>> rtmidi: PortMIDI module enabled
>>>>>>> memory allocate failure for 12
>>>>>>> end of score.              overall amps:      0.0      0.0
>>>>>>>         overall samples out of range:        0        0
>>>>>>> 0 errors in performance
>>>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>>>> warning: HEAP[csound.exe]:
>>>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>>>> 14
>>>>>>> 
>>>>>>> 
>>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> (gdb) bt
>>>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #2  0x025767c8 in ?? ()
>>>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>>>> #8  0x005b0000 in ?? ()
>>>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>>>  at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>>>  at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>>>  at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>>>  at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>>>> (gdb)
>>>>>>> 
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 00:52
FromVictor Lazzarini
SubjectRe: [Cs-dev] android out channels (chnset) (was Re: Csound crashing)
It turns out we’re defining USE_DOUBLE somewhere and that is causing the problem. I am not quite sure where.
I will investigate.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 19 Jul 2014, at 00:15, Victor Lazzarini  wrote:

> Another problem (maybe unrelated), chnset on android is broken. I tested it by adding the line
> 
> chnset p5*(1+ksl), "freq"
> 
> to test.csd (simple test app). And this to the java side
> 
> public void updateValuesFromCsound() {
> 				// TODO Auto-generated method stub
> 				float f =  csoundObj.getCsound().GetChannel("freq");
> 				Log.d("CsoundAndroidActivity", "freq: " + f);	
> 			}
> 
> Instead of getting correct values in the range  440-880, I am getting values such as
> 
> 07-19 00:10:21.490: D/CsoundAndroidActivity(672): freq: -1.5881865E-23
> 
> this does not seem to happen on the desktop, so I am wondering what the problem is. Any ideas
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 18 Jul 2014, at 17:08, Steven Yi  wrote:
> 
>> And another note, OSX is working, but Windows is not again.  I'm
>> digging into this but I have to step away for a bit, and will resume
>> when I get back later today.
>> 
>> On Fri, Jul 18, 2014 at 11:05 AM, Steven Yi  wrote:
>>> Just a side note, I just made a commit that got things working on
>>> Windows (some bad pointer arithmetic). However, I just tried it on OSX
>>> and am now getting crashes there. Hopefully should go a little quicker
>>> as it's a little easier for me to debug on OSX. I'll update here as
>>> soon as I get something fully working.
>>> 
>>> On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
>>>> Hi Victor,
>>>> 
>>>> Thanks for testing and confirming that.  I'll do some investigation
>>>> first on Windows as I can use gdb easily there, and will look to test
>>>> any fixes on Android before committing.
>>>> 
>>>> Thanks!
>>>> steven
>>>> 
>>>> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>>>>  wrote:
>>>>> yes, I reverted to before the branch merge and the android examples are working again.
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>>>> 
>>>>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>>>> 
>>>>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>>>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>>>> 
>>>>>> I’ll revert locally and test again.
>>>>>> 
>>>>>> Victor
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> NUI Maynooth, Ireland
>>>>>> victor dot lazzarini at nuim dot ie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>>>> 
>>>>>>> I wonder if it is one of two things I worked on: one was changing the
>>>>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>>>>> using a new macro.  The error would seem to point to one of those two
>>>>>>> changes causing an issue.
>>>>>>> 
>>>>>>> Last time something like this happened, where there was a
>>>>>>> memory-related crash only on windows, I seem to remember an alignment
>>>>>>> issue. The error message is a bit ambiguous about the allocation of
>>>>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>>>> 
>>>>>>> I've written a note to take a look at this in the morning.
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>> 
>>>>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>>>>> stack trace.
>>>>>>>> 
>>>>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>>>>> declared inconsistently.
>>>>>>>> 
>>>>>>>> What has changed?
>>>>>>>> 
>>>>>>>> [New Thread 68.0x660]
>>>>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>>>>> 0dBFS level = 32768.0
>>>>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>>>>> libsndfile-1.0.25
>>>>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>>>>> STARTING FILE
>>>>>>>> Creating options
>>>>>>>> Creating orchestra
>>>>>>>> Creating score
>>>>>>>> rtaudio: PortAudio module enabled ...
>>>>>>>> using callback interface
>>>>>>>> rtmidi: PortMIDI module enabled
>>>>>>>> memory allocate failure for 12
>>>>>>>> end of score.              overall amps:      0.0      0.0
>>>>>>>>        overall samples out of range:        0        0
>>>>>>>> 0 errors in performance
>>>>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>>>>> warning: HEAP[csound.exe]:
>>>>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>>>>> 14
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> (gdb) bt
>>>>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #2  0x025767c8 in ?? ()
>>>>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>>>>> #8  0x005b0000 in ?? ()
>>>>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>>>> at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>>>> at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>>>> at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>>>> at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>>>>> (gdb)
>>>>>>>> 
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 00:56
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Update: I think I've found the root cause, but will need to take a
little more time to sort it out.  What I'm finding is that with OSX
and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
gcc is giving a sizeof(CS_VAR_MEM) = 16.  Also, with gcc and Windows,
with &(varMem->memBlock), I am getting an address 8 from the beginning
of the varMem, while on clang/OSX I am getting an address 4 from the
beginning.

I'm pretty certain this is the cause, as it'd throw the pointer
arithmetic all off. I will continue to explore this and will report
again hopefully when fixed.

On Fri, Jul 18, 2014 at 12:08 PM, Steven Yi  wrote:
> And another note, OSX is working, but Windows is not again.  I'm
> digging into this but I have to step away for a bit, and will resume
> when I get back later today.
>
> On Fri, Jul 18, 2014 at 11:05 AM, Steven Yi  wrote:
>> Just a side note, I just made a commit that got things working on
>> Windows (some bad pointer arithmetic). However, I just tried it on OSX
>> and am now getting crashes there. Hopefully should go a little quicker
>> as it's a little easier for me to debug on OSX. I'll update here as
>> soon as I get something fully working.
>>
>> On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
>>> Hi Victor,
>>>
>>> Thanks for testing and confirming that.  I'll do some investigation
>>> first on Windows as I can use gdb easily there, and will look to test
>>> any fixes on Android before committing.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>>>  wrote:
>>>> yes, I reverted to before the branch merge and the android examples are working again.
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>>>
>>>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>>>
>>>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>>>
>>>>> I’ll revert locally and test again.
>>>>>
>>>>> Victor
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>>>
>>>>>> I wonder if it is one of two things I worked on: one was changing the
>>>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>>>> using a new macro.  The error would seem to point to one of those two
>>>>>> changes causing an issue.
>>>>>>
>>>>>> Last time something like this happened, where there was a
>>>>>> memory-related crash only on windows, I seem to remember an alignment
>>>>>> issue. The error message is a bit ambiguous about the allocation of
>>>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>>>
>>>>>> I've written a note to take a look at this in the morning.
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>>>> stack trace.
>>>>>>>
>>>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>>>> declared inconsistently.
>>>>>>>
>>>>>>> What has changed?
>>>>>>>
>>>>>>> [New Thread 68.0x660]
>>>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>>>> 0dBFS level = 32768.0
>>>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>>>> libsndfile-1.0.25
>>>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>>>> STARTING FILE
>>>>>>> Creating options
>>>>>>> Creating orchestra
>>>>>>> Creating score
>>>>>>> rtaudio: PortAudio module enabled ...
>>>>>>> using callback interface
>>>>>>> rtmidi: PortMIDI module enabled
>>>>>>> memory allocate failure for 12
>>>>>>> end of score.              overall amps:      0.0      0.0
>>>>>>>          overall samples out of range:        0        0
>>>>>>> 0 errors in performance
>>>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>>>> warning: HEAP[csound.exe]:
>>>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>>>> 14
>>>>>>>
>>>>>>>
>>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> (gdb) bt
>>>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #2  0x025767c8 in ?? ()
>>>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>>>> #8  0x005b0000 in ?? ()
>>>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>>>   at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>>>   at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>>>   at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>>>> (gdb)
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
http
Date2014-07-19 01:06
FromVictor Lazzarini
SubjectRe: [Cs-dev] android out channels (chnset) (was Re: Csound crashing)
yes, I had a float-version.h in my sources include (which I probably put there at some point), and that was interfering with the build.
Sorry for the noise.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 19 Jul 2014, at 00:52, Victor Lazzarini  wrote:

> It turns out we’re defining USE_DOUBLE somewhere and that is causing the problem. I am not quite sure where.
> I will investigate.
> 
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 19 Jul 2014, at 00:15, Victor Lazzarini  wrote:
> 
>> Another problem (maybe unrelated), chnset on android is broken. I tested it by adding the line
>> 
>> chnset p5*(1+ksl), "freq"
>> 
>> to test.csd (simple test app). And this to the java side
>> 
>> public void updateValuesFromCsound() {
>> 				// TODO Auto-generated method stub
>> 				float f =  csoundObj.getCsound().GetChannel("freq");
>> 				Log.d("CsoundAndroidActivity", "freq: " + f);	
>> 			}
>> 
>> Instead of getting correct values in the range  440-880, I am getting values such as
>> 
>> 07-19 00:10:21.490: D/CsoundAndroidActivity(672): freq: -1.5881865E-23
>> 
>> this does not seem to happen on the desktop, so I am wondering what the problem is. Any ideas
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 18 Jul 2014, at 17:08, Steven Yi  wrote:
>> 
>>> And another note, OSX is working, but Windows is not again.  I'm
>>> digging into this but I have to step away for a bit, and will resume
>>> when I get back later today.
>>> 
>>> On Fri, Jul 18, 2014 at 11:05 AM, Steven Yi  wrote:
>>>> Just a side note, I just made a commit that got things working on
>>>> Windows (some bad pointer arithmetic). However, I just tried it on OSX
>>>> and am now getting crashes there. Hopefully should go a little quicker
>>>> as it's a little easier for me to debug on OSX. I'll update here as
>>>> soon as I get something fully working.
>>>> 
>>>> On Fri, Jul 18, 2014 at 8:34 AM, Steven Yi  wrote:
>>>>> Hi Victor,
>>>>> 
>>>>> Thanks for testing and confirming that.  I'll do some investigation
>>>>> first on Windows as I can use gdb easily there, and will look to test
>>>>> any fixes on Android before committing.
>>>>> 
>>>>> Thanks!
>>>>> steven
>>>>> 
>>>>> On Fri, Jul 18, 2014 at 5:57 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> yes, I reverted to before the branch merge and the android examples are working again.
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> NUI Maynooth, Ireland
>>>>>> victor dot lazzarini at nuim dot ie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 18 Jul 2014, at 10:42, Victor Lazzarini  wrote:
>>>>>> 
>>>>>>> I think there might be some issue in this new code, because the Android code is also crashing:
>>>>>>> 
>>>>>>> 07-18 10:40:59.526: D/CsoundObj(623): Creating score
>>>>>>> 07-18 10:40:59.566: A/libc(623): @@@ ABORTING: INVALID HEAP ADDRESS IN internal_realloc addr=0x2a2602fc
>>>>>>> 
>>>>>>> I’ll revert locally and test again.
>>>>>>> 
>>>>>>> Victor
>>>>>>> ========================
>>>>>>> Dr Victor Lazzarini
>>>>>>> Senior Lecturer
>>>>>>> NUI Maynooth, Ireland
>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 18 Jul 2014, at 04:34, Steven Yi  wrote:
>>>>>>> 
>>>>>>>> I wonder if it is one of two things I worked on: one was changing the
>>>>>>>> allocation for CS_VAR_MEM and RTTI, the other is alignment of memory
>>>>>>>> using a new macro.  The error would seem to point to one of those two
>>>>>>>> changes causing an issue.
>>>>>>>> 
>>>>>>>> Last time something like this happened, where there was a
>>>>>>>> memory-related crash only on windows, I seem to remember an alignment
>>>>>>>> issue. The error message is a bit ambiguous about the allocation of
>>>>>>>> size 12 (that would be the size of a CS_VAR_MEM though...).
>>>>>>>> 
>>>>>>>> I've written a note to take a look at this in the morning.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>> 
>>>>>>>> On Thu, Jul 17, 2014 at 9:43 PM, Michael Gogins
>>>>>>>>  wrote:
>>>>>>>>> On Windows 8, built with MinGW 4.8.2 from Qt SDK with Posix threading model
>>>>>>>>> and dw2 exception handling, Csound now always crashes with the following
>>>>>>>>> stack trace.
>>>>>>>>> 
>>>>>>>>> I suspect that the size of some element in the CSOUND struct, possibly the
>>>>>>>>> pthread_t objects which have been a source of trouble in the past, are now
>>>>>>>>> declared inconsistently.
>>>>>>>>> 
>>>>>>>>> What has changed?
>>>>>>>>> 
>>>>>>>>> [New Thread 68.0x660]
>>>>>>>>> virtual_keyboard real time MIDI plugin for Csound
>>>>>>>>> 0dBFS level = 32768.0
>>>>>>>>> Csound version 6.03.2 (double samples) Jul 17 2014
>>>>>>>>> libsndfile-1.0.25
>>>>>>>>> UnifiedCSD:  ..\examples\trapped.csd
>>>>>>>>> STARTING FILE
>>>>>>>>> Creating options
>>>>>>>>> Creating orchestra
>>>>>>>>> Creating score
>>>>>>>>> rtaudio: PortAudio module enabled ...
>>>>>>>>> using callback interface
>>>>>>>>> rtmidi: PortMIDI module enabled
>>>>>>>>> memory allocate failure for 12
>>>>>>>>> end of score.              overall amps:      0.0      0.0
>>>>>>>>>       overall samples out of range:        0        0
>>>>>>>>> 0 errors in performance
>>>>>>>>> Elapsed time at end of performance: real: 0.068s, CPU: 0.078s
>>>>>>>>> warning: HEAP[csound.exe]:
>>>>>>>>> warning: Heap block at 025767C8 modified at 025767E4 past requested size of
>>>>>>>>> 14
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>>>>>> 0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> (gdb) bt
>>>>>>>>> #0  0x775dc156 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #1  0x775c095b in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #2  0x025767c8 in ?? ()
>>>>>>>>> #3  0x775919ff in ntdll!RtlCreateUserThread ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #4  0x775dcf63 in ntdll!RtlpNtMakeTemporaryKey ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #5  0x77588973 in ntdll!RtlCreateUserThread ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #6  0x77552664 in ntdll!RtlAcquireSRWLockExclusive ()
>>>>>>>>> from C:\Windows\SYSTEM32\ntdll.dll
>>>>>>>>> #7  0x76d49b03 in msvcrt!free () from C:\Windows\SysWOW64\msvcrt.dll
>>>>>>>>> #8  0x005b0000 in ?? ()
>>>>>>>>> #9  0x6c5136bc in memRESET (csound=csound@entry=0x5c0048)
>>>>>>>>> at c:/Users/mike/csound-csound6-git/Engine/memalloc.c:230
>>>>>>>>> #10 0x6c5eab86 in reset (csound=csound@entry=0x5c0048)
>>>>>>>>> at c:/Users/mike/csound-csound6-git/Top/csound.c:2913
>>>>>>>>> #11 0x6c5ec3c0 in csoundDestroy (csound=0x5c0048)
>>>>>>>>> at c:/Users/mike/csound-csound6-git/Top/csound.c:1224
>>>>>>>>> #12 0x00402a5c in main (argc=2, argv=0x5b2fb0)
>>>>>>>>> at c:/Users/mike/csound-csound6-git/frontends/csound/csound_main.c:137
>>>>>>>>> (gdb)
>>>>>>>>> 
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Michael Gogins
>>>>>>>>> Irreducible Productions
>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 03:16
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
AttachmentsNone  None  


On 18 Jul 2014 19:57, "Steven Yi" <stevenyi@gmail.com> wrote:
>
> Update: I think I've found the root cause, but will need to take a
> little more time to sort it out.  What I'm finding is that with OSX
> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
> gcc is giving a sizeof(CS_VAR_MEM) = 16.  

It need not be so. Compilers and architectures differ on alignment requirements, so there is no guarantee that a field after a 4 byte field will be 4 bytes after it.

There are a few gcc attributes that control the packing of the structs, but I hear that playing with those should only be done Knowing What You Are Doing (tm), otherwise behavior is undefined.

Liblo did some tricks like these and ended up not working on some architectures in debian.

Saludos

Date2014-07-19 05:02
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Hi Felipe,

Yes this is turning out to be a very interesting problem that I had
not expected. :)  I think the solution may be to use MYFLT in the
CS_MEM_VAR to store the value of the pointer.  It should make the
pointer arithmetic work to read from the memBlock member and go back
one MYFLT in space, then use as a CS_TYPE*.  I think that should work
cross-platform/compiler.

I'll be working on this tomorrow morning. Hopefully works out!

steven

On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler  wrote:
>
> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>
>> Update: I think I've found the root cause, but will need to take a
>> little more time to sort it out.  What I'm finding is that with OSX
>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>
> It need not be so. Compilers and architectures differ on alignment
> requirements, so there is no guarantee that a field after a 4 byte field
> will be 4 bytes after it.
>
> There are a few gcc attributes that control the packing of the structs, but
> I hear that playing with those should only be done Knowing What You Are
> Doing (tm), otherwise behavior is undefined.
>
> Liblo did some tricks like these and ended up not working on some
> architectures in debian.
>
> Saludos
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 09:20
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
I find it strange that sizeof(CS_TYPE*) is 4 on OSX,  because it is a 64bit OS, and pointers
should be 8 bytes long. On Windows (32), I would expect the reverse, pointer sizes being 4 bytes.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 19 Jul 2014, at 05:02, Steven Yi  wrote:

> Hi Felipe,
> 
> Yes this is turning out to be a very interesting problem that I had
> not expected. :)  I think the solution may be to use MYFLT in the
> CS_MEM_VAR to store the value of the pointer.  It should make the
> pointer arithmetic work to read from the memBlock member and go back
> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
> cross-platform/compiler.
> 
> I'll be working on this tomorrow morning. Hopefully works out!
> 
> steven
> 
> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler  wrote:
>> 
>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>> 
>>> Update: I think I've found the root cause, but will need to take a
>>> little more time to sort it out.  What I'm finding is that with OSX
>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>> 
>> It need not be so. Compilers and architectures differ on alignment
>> requirements, so there is no guarantee that a field after a 4 byte field
>> will be 4 bytes after it.
>> 
>> There are a few gcc attributes that control the packing of the structs, but
>> I hear that playing with those should only be done Knowing What You Are
>> Doing (tm), otherwise behavior is undefined.
>> 
>> Liblo did some tricks like these and ended up not working on some
>> architectures in debian.
>> 
>> Saludos
>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 11:14
Fromjpff@cs.bath.ac.uk
SubjectRe: [Cs-dev] Csound crashing
AttachmentsNone  
Date2014-07-19 11:32
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
This is what confused me, on OSX, which defaults to x86_64, CS_TYPE* surely is 8 bytes, unless you are forcing i386.
On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:

> This really sounds wrong.  You cannot guarantee that a MYFLT can hold  
> a CS_TYPE*
> (Think 64but architecture with floats)
> 
> This kind of laying is an invitation to problems as Felipe said.
> 
> Can we do this cleanly?  Still asleep so have not looked at what you  
> are attempting
> 
> =John
> 
> Quoting Steven Yi :
> 
>> Hi Felipe,
>> 
>> Yes this is turning out to be a very interesting problem that I had
>> not expected. :)  I think the solution may be to use MYFLT in the
>> CS_MEM_VAR to store the value of the pointer.  It should make the
>> pointer arithmetic work to read from the memBlock member and go back
>> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>> cross-platform/compiler.
>> 
>> I'll be working on this tomorrow morning. Hopefully works out!
>> 
>> steven
>> 
>> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler  wrote:
>>> 
>>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>>> 
>>>> Update: I think I've found the root cause, but will need to take a
>>>> little more time to sort it out.  What I'm finding is that with OSX
>>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
>>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
>>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>>> 
>>> It need not be so. Compilers and architectures differ on alignment
>>> requirements, so there is no guarantee that a field after a 4 byte field
>>> will be 4 bytes after it.
>>> 
>>> There are a few gcc attributes that control the packing of the structs, but
>>> I hear that playing with those should only be done Knowing What You Are
>>> Doing (tm), otherwise behavior is undefined.
>>> 
>>> Liblo did some tricks like these and ended up not working on some
>>> architectures in debian.
>>> 
>>> Saludos
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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




------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 14:35
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
AttachmentsNone  None  

Sorry, I didn't mention that I was using i386 mode for development on OSX. That matches the windows build for comparing apples to apples.

Perhaps the path with myflt is misguided. I looked a little into the compiler option for __aligned__ and packed. I'll look into that again now.

On Jul 19, 2014 6:33 AM, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:
This is what confused me, on OSX, which defaults to x86_64, CS_TYPE* surely is 8 bytes, unless you are forcing i386.
On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:

> This really sounds wrong.  You cannot guarantee that a MYFLT can hold
> a CS_TYPE*
> (Think 64but architecture with floats)
>
> This kind of laying is an invitation to problems as Felipe said.
>
> Can we do this cleanly?  Still asleep so have not looked at what you
> are attempting
>
> =John
>
> Quoting Steven Yi <stevenyi@gmail.com>:
>
>> Hi Felipe,
>>
>> Yes this is turning out to be a very interesting problem that I had
>> not expected. :)  I think the solution may be to use MYFLT in the
>> CS_MEM_VAR to store the value of the pointer.  It should make the
>> pointer arithmetic work to read from the memBlock member and go back
>> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>> cross-platform/compiler.
>>
>> I'll be working on this tomorrow morning. Hopefully works out!
>>
>> steven
>>
>> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler <fsateler@gmail.com> wrote:
>>>
>>> On 18 Jul 2014 19:57, "Steven Yi" <stevenyi@gmail.com> wrote:
>>>>
>>>> Update: I think I've found the root cause, but will need to take a
>>>> little more time to sort it out.  What I'm finding is that with OSX
>>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should be,
>>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on Windows,
>>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>>>
>>> It need not be so. Compilers and architectures differ on alignment
>>> requirements, so there is no guarantee that a field after a 4 byte field
>>> will be 4 bytes after it.
>>>
>>> There are a few gcc attributes that control the packing of the structs, but
>>> I hear that playing with those should only be done Knowing What You Are
>>> Doing (tm), otherwise behavior is undefined.
>>>
>>> Liblo did some tricks like these and ended up not working on some
>>> architectures in debian.
>>>
>>> Saludos
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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




------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel
Date2014-07-19 14:55
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Aligned and packing seemed to be a dark path to walk down.  I have
another idea to calculate the values based on sizeof(CS_VAR_MEM)
rather than sizeof(CS_TYPE).  I think that should work to align things
correctly, even for the pfields in INSDS.  Trying that now.

On Sat, Jul 19, 2014 at 9:35 AM, Steven Yi  wrote:
> Sorry, I didn't mention that I was using i386 mode for development on OSX.
> That matches the windows build for comparing apples to apples.
>
> Perhaps the path with myflt is misguided. I looked a little into the
> compiler option for __aligned__ and packed. I'll look into that again now.
>
> On Jul 19, 2014 6:33 AM, "Victor Lazzarini" 
> wrote:
>>
>> This is what confused me, on OSX, which defaults to x86_64, CS_TYPE*
>> surely is 8 bytes, unless you are forcing i386.
>> On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>
>> > This really sounds wrong.  You cannot guarantee that a MYFLT can hold
>> > a CS_TYPE*
>> > (Think 64but architecture with floats)
>> >
>> > This kind of laying is an invitation to problems as Felipe said.
>> >
>> > Can we do this cleanly?  Still asleep so have not looked at what you
>> > are attempting
>> >
>> > =John
>> >
>> > Quoting Steven Yi :
>> >
>> >> Hi Felipe,
>> >>
>> >> Yes this is turning out to be a very interesting problem that I had
>> >> not expected. :)  I think the solution may be to use MYFLT in the
>> >> CS_MEM_VAR to store the value of the pointer.  It should make the
>> >> pointer arithmetic work to read from the memBlock member and go back
>> >> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>> >> cross-platform/compiler.
>> >>
>> >> I'll be working on this tomorrow morning. Hopefully works out!
>> >>
>> >> steven
>> >>
>> >> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler 
>> >> wrote:
>> >>>
>> >>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>> >>>>
>> >>>> Update: I think I've found the root cause, but will need to take a
>> >>>> little more time to sort it out.  What I'm finding is that with OSX
>> >>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should
>> >>>> be,
>> >>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on
>> >>>> Windows,
>> >>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>> >>>
>> >>> It need not be so. Compilers and architectures differ on alignment
>> >>> requirements, so there is no guarantee that a field after a 4 byte
>> >>> field
>> >>> will be 4 bytes after it.
>> >>>
>> >>> There are a few gcc attributes that control the packing of the
>> >>> structs, but
>> >>> I hear that playing with those should only be done Knowing What You
>> >>> Are
>> >>> Doing (tm), otherwise behavior is undefined.
>> >>>
>> >>> Liblo did some tricks like these and ended up not working on some
>> >>> architectures in debian.
>> >>>
>> >>> Saludos
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Want fast and easy access to all the code in your enterprise? Index
>> >>> and
>> >>> search up to 200,000 lines of code with a free copy of Black Duck
>> >>> Code Sight - the same software that powers the world's largest code
>> >>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> >>> http://p.sf.net/sfu/bds
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Want fast and easy access to all the code in your enterprise? Index and
>> >> search up to 200,000 lines of code with a free copy of Black Duck
>> >> Code Sight - the same software that powers the world's largest code
>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>> >> http://p.sf.net/sfu/bds
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Want fast and easy access to all the code in your enterprise? Index and
>> > search up to 200,000 lines of code with a free copy of Black Duck
>> > Code Sight - the same software that powers the world's largest code
>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>> > http://p.sf.net/sfu/bds
>> > _______________________________________________
>> > 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
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 15:22
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
work.  I have tested with OSX (both i386 and x86_64 builds), and on
Windows.  The path I took was to take into account how much space was
used for CS_VAR_MEM's varType member, including padding, to calculate
based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
memBlock, then subtracting sizeof MYFLT would then give the full
memory size used by varMem + any padding.  That allows to then use
that calculated size to do pointer arithmetic via char* to get the
location of the type correctly.

Also, I was allocating CS_VAR_MEM's manually in some places as
sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
sizeof(MYFLT) + var->memBlockSize.

I've got to take a break now, but will look at Android if someone else
hasn't tested beforehand.

Thanks!
steven



On Sat, Jul 19, 2014 at 9:55 AM, Steven Yi  wrote:
> Aligned and packing seemed to be a dark path to walk down.  I have
> another idea to calculate the values based on sizeof(CS_VAR_MEM)
> rather than sizeof(CS_TYPE).  I think that should work to align things
> correctly, even for the pfields in INSDS.  Trying that now.
>
> On Sat, Jul 19, 2014 at 9:35 AM, Steven Yi  wrote:
>> Sorry, I didn't mention that I was using i386 mode for development on OSX.
>> That matches the windows build for comparing apples to apples.
>>
>> Perhaps the path with myflt is misguided. I looked a little into the
>> compiler option for __aligned__ and packed. I'll look into that again now.
>>
>> On Jul 19, 2014 6:33 AM, "Victor Lazzarini" 
>> wrote:
>>>
>>> This is what confused me, on OSX, which defaults to x86_64, CS_TYPE*
>>> surely is 8 bytes, unless you are forcing i386.
>>> On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>
>>> > This really sounds wrong.  You cannot guarantee that a MYFLT can hold
>>> > a CS_TYPE*
>>> > (Think 64but architecture with floats)
>>> >
>>> > This kind of laying is an invitation to problems as Felipe said.
>>> >
>>> > Can we do this cleanly?  Still asleep so have not looked at what you
>>> > are attempting
>>> >
>>> > =John
>>> >
>>> > Quoting Steven Yi :
>>> >
>>> >> Hi Felipe,
>>> >>
>>> >> Yes this is turning out to be a very interesting problem that I had
>>> >> not expected. :)  I think the solution may be to use MYFLT in the
>>> >> CS_MEM_VAR to store the value of the pointer.  It should make the
>>> >> pointer arithmetic work to read from the memBlock member and go back
>>> >> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>>> >> cross-platform/compiler.
>>> >>
>>> >> I'll be working on this tomorrow morning. Hopefully works out!
>>> >>
>>> >> steven
>>> >>
>>> >> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler 
>>> >> wrote:
>>> >>>
>>> >>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>> >>>>
>>> >>>> Update: I think I've found the root cause, but will need to take a
>>> >>>> little more time to sort it out.  What I'm finding is that with OSX
>>> >>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should
>>> >>>> be,
>>> >>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on
>>> >>>> Windows,
>>> >>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>>> >>>
>>> >>> It need not be so. Compilers and architectures differ on alignment
>>> >>> requirements, so there is no guarantee that a field after a 4 byte
>>> >>> field
>>> >>> will be 4 bytes after it.
>>> >>>
>>> >>> There are a few gcc attributes that control the packing of the
>>> >>> structs, but
>>> >>> I hear that playing with those should only be done Knowing What You
>>> >>> Are
>>> >>> Doing (tm), otherwise behavior is undefined.
>>> >>>
>>> >>> Liblo did some tricks like these and ended up not working on some
>>> >>> architectures in debian.
>>> >>>
>>> >>> Saludos
>>> >>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> Want fast and easy access to all the code in your enterprise? Index
>>> >>> and
>>> >>> search up to 200,000 lines of code with a free copy of Black Duck
>>> >>> Code Sight - the same software that powers the world's largest code
>>> >>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> >>> http://p.sf.net/sfu/bds
>>> >>> _______________________________________________
>>> >>> Csound-devel mailing list
>>> >>> Csound-devel@lists.sourceforge.net
>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Want fast and easy access to all the code in your enterprise? Index and
>>> >> search up to 200,000 lines of code with a free copy of Black Duck
>>> >> Code Sight - the same software that powers the world's largest code
>>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> >> http://p.sf.net/sfu/bds
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Want fast and easy access to all the code in your enterprise? Index and
>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>> > Code Sight - the same software that powers the world's largest code
>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>> > http://p.sf.net/sfu/bds
>>> > _______________________________________________
>>> > 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
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 15:52
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
I think android is fine. The crash was due to USE_DOUBLE being defined by mistake in my build, or at least it looks like it

VL


On 19 Jul 2014, at 15:22, Steven Yi  wrote:

> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
> work.  I have tested with OSX (both i386 and x86_64 builds), and on
> Windows.  The path I took was to take into account how much space was
> used for CS_VAR_MEM's varType member, including padding, to calculate
> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
> memBlock, then subtracting sizeof MYFLT would then give the full
> memory size used by varMem + any padding.  That allows to then use
> that calculated size to do pointer arithmetic via char* to get the
> location of the type correctly.
> 
> Also, I was allocating CS_VAR_MEM's manually in some places as
> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
> sizeof(MYFLT) + var->memBlockSize.
> 
> I've got to take a break now, but will look at Android if someone else
> hasn't tested beforehand.
> 
> Thanks!
> steven
> 
> 
> 
> On Sat, Jul 19, 2014 at 9:55 AM, Steven Yi  wrote:
>> Aligned and packing seemed to be a dark path to walk down.  I have
>> another idea to calculate the values based on sizeof(CS_VAR_MEM)
>> rather than sizeof(CS_TYPE).  I think that should work to align things
>> correctly, even for the pfields in INSDS.  Trying that now.
>> 
>> On Sat, Jul 19, 2014 at 9:35 AM, Steven Yi  wrote:
>>> Sorry, I didn't mention that I was using i386 mode for development on OSX.
>>> That matches the windows build for comparing apples to apples.
>>> 
>>> Perhaps the path with myflt is misguided. I looked a little into the
>>> compiler option for __aligned__ and packed. I'll look into that again now.
>>> 
>>> On Jul 19, 2014 6:33 AM, "Victor Lazzarini" 
>>> wrote:
>>>> 
>>>> This is what confused me, on OSX, which defaults to x86_64, CS_TYPE*
>>>> surely is 8 bytes, unless you are forcing i386.
>>>> On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>> 
>>>>> This really sounds wrong.  You cannot guarantee that a MYFLT can hold
>>>>> a CS_TYPE*
>>>>> (Think 64but architecture with floats)
>>>>> 
>>>>> This kind of laying is an invitation to problems as Felipe said.
>>>>> 
>>>>> Can we do this cleanly?  Still asleep so have not looked at what you
>>>>> are attempting
>>>>> 
>>>>> =John
>>>>> 
>>>>> Quoting Steven Yi :
>>>>> 
>>>>>> Hi Felipe,
>>>>>> 
>>>>>> Yes this is turning out to be a very interesting problem that I had
>>>>>> not expected. :)  I think the solution may be to use MYFLT in the
>>>>>> CS_MEM_VAR to store the value of the pointer.  It should make the
>>>>>> pointer arithmetic work to read from the memBlock member and go back
>>>>>> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>>>>>> cross-platform/compiler.
>>>>>> 
>>>>>> I'll be working on this tomorrow morning. Hopefully works out!
>>>>>> 
>>>>>> steven
>>>>>> 
>>>>>> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>>>>>>> 
>>>>>>>> Update: I think I've found the root cause, but will need to take a
>>>>>>>> little more time to sort it out.  What I'm finding is that with OSX
>>>>>>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should
>>>>>>>> be,
>>>>>>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on
>>>>>>>> Windows,
>>>>>>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>>>>>>> 
>>>>>>> It need not be so. Compilers and architectures differ on alignment
>>>>>>> requirements, so there is no guarantee that a field after a 4 byte
>>>>>>> field
>>>>>>> will be 4 bytes after it.
>>>>>>> 
>>>>>>> There are a few gcc attributes that control the packing of the
>>>>>>> structs, but
>>>>>>> I hear that playing with those should only be done Knowing What You
>>>>>>> Are
>>>>>>> Doing (tm), otherwise behavior is undefined.
>>>>>>> 
>>>>>>> Liblo did some tricks like these and ended up not working on some
>>>>>>> architectures in debian.
>>>>>>> 
>>>>>>> Saludos
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>>>> and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 16:20
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
> work.  I have tested with OSX (both i386 and x86_64 builds), and on
> Windows.  The path I took was to take into account how much space was
> used for CS_VAR_MEM's varType member, including padding, to calculate
> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
> memBlock, then subtracting sizeof MYFLT would then give the full
> memory size used by varMem + any padding.  That allows to then use
> that calculated size to do pointer arithmetic via char* to get the
> location of the type correctly.

I'm not sure this assumption holds. Because if
(sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
the compiler needs to  add some padding, otherwise a dynamic array
malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
will not align on the second element.

> Also, I was allocating CS_VAR_MEM's manually in some places as
> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
> sizeof(MYFLT) + var->memBlockSize.

Same as above here.


I'm thinking we could leverage the debian infrastructure to test this.
If you can provide a test program that fails if the assumption doesn't
hold, I could build it on the following architectures:

armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
mipsel powerpc ppc64el s390x sh4 sparc


Hopefully that is a wide enough test net.

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 17:05
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Hi Felipe,

That's a good point, but I think we don't have to worry about the
memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
array, then the code is done where it is allocating CS_VAR_MEM's
as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
the memBlock is actually larger than than the sizeof(MYFLT), the
CS_VAR_MEM is used in the global var pool, where it is accessed via
csVar->memBlock.  That leaves the only concern being the padding
between CS_TYPE* and MYFLT in the struct, which I think is accounted
for in the code.

I'll see about writing up a test file and will reply once I have a
chance (will be later tonight as I have to head out for the day).

Thanks!
steven

On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>> Windows.  The path I took was to take into account how much space was
>> used for CS_VAR_MEM's varType member, including padding, to calculate
>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>> memBlock, then subtracting sizeof MYFLT would then give the full
>> memory size used by varMem + any padding.  That allows to then use
>> that calculated size to do pointer arithmetic via char* to get the
>> location of the type correctly.
>
> I'm not sure this assumption holds. Because if
> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
> the compiler needs to  add some padding, otherwise a dynamic array
> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
> will not align on the second element.
>
>> Also, I was allocating CS_VAR_MEM's manually in some places as
>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>> sizeof(MYFLT) + var->memBlockSize.
>
> Same as above here.
>
>
> I'm thinking we could leverage the debian infrastructure to test this.
> If you can provide a test program that fails if the assumption doesn't
> hold, I could build it on the following architectures:
>
> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
> mipsel powerpc ppc64el s390x sh4 sparc
>
>
> Hopefully that is a wide enough test net.
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 17:06
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Hi Victor,

Thanks for mentioning that. I'll still test later tonight just in
case, as I do wonder about ARM and using gcc with the NDK.

Thanks!
steven

On Sat, Jul 19, 2014 at 10:52 AM, Victor Lazzarini
 wrote:
> I think android is fine. The crash was due to USE_DOUBLE being defined by mistake in my build, or at least it looks like it
>
> VL
>
>
> On 19 Jul 2014, at 15:22, Steven Yi  wrote:
>
>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>> Windows.  The path I took was to take into account how much space was
>> used for CS_VAR_MEM's varType member, including padding, to calculate
>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>> memBlock, then subtracting sizeof MYFLT would then give the full
>> memory size used by varMem + any padding.  That allows to then use
>> that calculated size to do pointer arithmetic via char* to get the
>> location of the type correctly.
>>
>> Also, I was allocating CS_VAR_MEM's manually in some places as
>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>> sizeof(MYFLT) + var->memBlockSize.
>>
>> I've got to take a break now, but will look at Android if someone else
>> hasn't tested beforehand.
>>
>> Thanks!
>> steven
>>
>>
>>
>> On Sat, Jul 19, 2014 at 9:55 AM, Steven Yi  wrote:
>>> Aligned and packing seemed to be a dark path to walk down.  I have
>>> another idea to calculate the values based on sizeof(CS_VAR_MEM)
>>> rather than sizeof(CS_TYPE).  I think that should work to align things
>>> correctly, even for the pfields in INSDS.  Trying that now.
>>>
>>> On Sat, Jul 19, 2014 at 9:35 AM, Steven Yi  wrote:
>>>> Sorry, I didn't mention that I was using i386 mode for development on OSX.
>>>> That matches the windows build for comparing apples to apples.
>>>>
>>>> Perhaps the path with myflt is misguided. I looked a little into the
>>>> compiler option for __aligned__ and packed. I'll look into that again now.
>>>>
>>>> On Jul 19, 2014 6:33 AM, "Victor Lazzarini" 
>>>> wrote:
>>>>>
>>>>> This is what confused me, on OSX, which defaults to x86_64, CS_TYPE*
>>>>> surely is 8 bytes, unless you are forcing i386.
>>>>> On 19 Jul 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>
>>>>>> This really sounds wrong.  You cannot guarantee that a MYFLT can hold
>>>>>> a CS_TYPE*
>>>>>> (Think 64but architecture with floats)
>>>>>>
>>>>>> This kind of laying is an invitation to problems as Felipe said.
>>>>>>
>>>>>> Can we do this cleanly?  Still asleep so have not looked at what you
>>>>>> are attempting
>>>>>>
>>>>>> =John
>>>>>>
>>>>>> Quoting Steven Yi :
>>>>>>
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> Yes this is turning out to be a very interesting problem that I had
>>>>>>> not expected. :)  I think the solution may be to use MYFLT in the
>>>>>>> CS_MEM_VAR to store the value of the pointer.  It should make the
>>>>>>> pointer arithmetic work to read from the memBlock member and go back
>>>>>>> one MYFLT in space, then use as a CS_TYPE*.  I think that should work
>>>>>>> cross-platform/compiler.
>>>>>>>
>>>>>>> I'll be working on this tomorrow morning. Hopefully works out!
>>>>>>>
>>>>>>> steven
>>>>>>>
>>>>>>> On Fri, Jul 18, 2014 at 10:16 PM, Felipe Sateler 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 18 Jul 2014 19:57, "Steven Yi"  wrote:
>>>>>>>>>
>>>>>>>>> Update: I think I've found the root cause, but will need to take a
>>>>>>>>> little more time to sort it out.  What I'm finding is that with OSX
>>>>>>>>> and clang, the sizeof(CS_VAR_MEM) is reporting as 12 (as it should
>>>>>>>>> be,
>>>>>>>>> as sizeof(CS_TYPE*) = 4, and sizeof(MYFLT) = 8).  However, on
>>>>>>>>> Windows,
>>>>>>>>> gcc is giving a sizeof(CS_VAR_MEM) = 16.
>>>>>>>>
>>>>>>>> It need not be so. Compilers and architectures differ on alignment
>>>>>>>> requirements, so there is no guarantee that a field after a 4 byte
>>>>>>>> field
>>>>>>>> will be 4 bytes after it.
>>>>>>>>
>>>>>>>> There are a few gcc attributes that control the packing of the
>>>>>>>> structs, but
>>>>>>>> I hear that playing with those should only be done Knowing What You
>>>>>>>> Are
>>>>>>>> Doing (tm), otherwise behavior is undefined.
>>>>>>>>
>>>>>>>> Liblo did some tricks like these and ended up not working on some
>>>>>>>> architectures in debian.
>>>>>>>>
>>>>>>>> Saludos
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>>>>> and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-19 23:42
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Attachmentstest.c  None  None  
Hi Felipe,

Attached is a test file that illustrates the kinds of things that are
happening with the RTTI code in Csound.

Thanks!
steven

On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
> Hi Felipe,
>
> That's a good point, but I think we don't have to worry about the
> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
> array, then the code is done where it is allocating CS_VAR_MEM's
> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
> the memBlock is actually larger than than the sizeof(MYFLT), the
> CS_VAR_MEM is used in the global var pool, where it is accessed via
> csVar->memBlock.  That leaves the only concern being the padding
> between CS_TYPE* and MYFLT in the struct, which I think is accounted
> for in the code.
>
> I'll see about writing up a test file and will reply once I have a
> chance (will be later tonight as I have to head out for the day).
>
> Thanks!
> steven
>
> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>> Windows.  The path I took was to take into account how much space was
>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>> memory size used by varMem + any padding.  That allows to then use
>>> that calculated size to do pointer arithmetic via char* to get the
>>> location of the type correctly.
>>
>> I'm not sure this assumption holds. Because if
>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>> the compiler needs to  add some padding, otherwise a dynamic array
>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>> will not align on the second element.
>>
>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>> sizeof(MYFLT) + var->memBlockSize.
>>
>> Same as above here.
>>
>>
>> I'm thinking we could leverage the debian infrastructure to test this.
>> If you can provide a test program that fails if the assumption doesn't
>> hold, I could build it on the following architectures:
>>
>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>> mipsel powerpc ppc64el s390x sh4 sparc
>>
>>
>> Hopefully that is a wide enough test net.
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
Date2014-07-20 01:24
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
Hi,

I ran the tests on several platforms (I didnt have access to all of them).

The results are at [1]. Unfortunately, this only seems to work on
x86-like architectures :(

[1] http://people.debian.org/~fsateler/testresults/result.log

On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
> Hi Felipe,
>
> Attached is a test file that illustrates the kinds of things that are
> happening with the RTTI code in Csound.
>
> Thanks!
> steven
>
> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>> Hi Felipe,
>>
>> That's a good point, but I think we don't have to worry about the
>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>> array, then the code is done where it is allocating CS_VAR_MEM's
>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>> the memBlock is actually larger than than the sizeof(MYFLT), the
>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>> csVar->memBlock.  That leaves the only concern being the padding
>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>> for in the code.
>>
>> I'll see about writing up a test file and will reply once I have a
>> chance (will be later tonight as I have to head out for the day).
>>
>> Thanks!
>> steven
>>
>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>> Windows.  The path I took was to take into account how much space was
>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>> memory size used by varMem + any padding.  That allows to then use
>>>> that calculated size to do pointer arithmetic via char* to get the
>>>> location of the type correctly.
>>>
>>> I'm not sure this assumption holds. Because if
>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>> the compiler needs to  add some padding, otherwise a dynamic array
>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>> will not align on the second element.
>>>
>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>> sizeof(MYFLT) + var->memBlockSize.
>>>
>>> Same as above here.
>>>
>>>
>>> I'm thinking we could leverage the debian infrastructure to test this.
>>> If you can provide a test program that fails if the assumption doesn't
>>> hold, I could build it on the following architectures:
>>>
>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>
>>>
>>> Hopefully that is a wide enough test net.
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-20 01:56
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Attachmentstest.c  None  None  
Hi Felipe,

Thanks very much for this.  At least there are no crashes. :)

I've added just a little more debugging information to the test to
print out pointer addresses and sizes of things.  Could you by chance
run this test when you have a chance?

Thanks!
steven

On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
> Hi,
>
> I ran the tests on several platforms (I didnt have access to all of them).
>
> The results are at [1]. Unfortunately, this only seems to work on
> x86-like architectures :(
>
> [1] http://people.debian.org/~fsateler/testresults/result.log
>
> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>> Hi Felipe,
>>
>> Attached is a test file that illustrates the kinds of things that are
>> happening with the RTTI code in Csound.
>>
>> Thanks!
>> steven
>>
>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> That's a good point, but I think we don't have to worry about the
>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>> csVar->memBlock.  That leaves the only concern being the padding
>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>> for in the code.
>>>
>>> I'll see about writing up a test file and will reply once I have a
>>> chance (will be later tonight as I have to head out for the day).
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>> Windows.  The path I took was to take into account how much space was
>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>> location of the type correctly.
>>>>
>>>> I'm not sure this assumption holds. Because if
>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>> will not align on the second element.
>>>>
>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>
>>>> Same as above here.
>>>>
>>>>
>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>> If you can provide a test program that fails if the assumption doesn't
>>>> hold, I could build it on the following architectures:
>>>>
>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>
>>>>
>>>> Hopefully that is a wide enough test net.
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
Date2014-07-20 02:10
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Just another note, we could just remove the p0_type/p0, and make p0,
p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
test.c, it might be a possible solution.

On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
> Hi Felipe,
>
> Thanks very much for this.  At least there are no crashes. :)
>
> I've added just a little more debugging information to the test to
> print out pointer addresses and sizes of things.  Could you by chance
> run this test when you have a chance?
>
> Thanks!
> steven
>
> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>> Hi,
>>
>> I ran the tests on several platforms (I didnt have access to all of them).
>>
>> The results are at [1]. Unfortunately, this only seems to work on
>> x86-like architectures :(
>>
>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>
>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> Attached is a test file that illustrates the kinds of things that are
>>> happening with the RTTI code in Csound.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>> Hi Felipe,
>>>>
>>>> That's a good point, but I think we don't have to worry about the
>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>> for in the code.
>>>>
>>>> I'll see about writing up a test file and will reply once I have a
>>>> chance (will be later tonight as I have to head out for the day).
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>> location of the type correctly.
>>>>>
>>>>> I'm not sure this assumption holds. Because if
>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>> will not align on the second element.
>>>>>
>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>
>>>>> Same as above here.
>>>>>
>>>>>
>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>> hold, I could build it on the following architectures:
>>>>>
>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>
>>>>>
>>>>> Hopefully that is a wide enough test net.
>>>>>
>>>>> --
>>>>>
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-20 17:09
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Just to note, I built and ran the CsoundAndroidExamples project on my
Nexus 4.  I did not experience any issues running the examples.  I
suspect that the RTTI stuff may not be working correctly since the ARM
compile failed in Felipe's tests.  I think then with the latest that
Csound is in the same shape as it was before RTTI, and RTTI is only
working on x86 based processors.  We can work on the RTTI stuff
separately and it shouldn't interfere with any other work at this
time.

Thanks!
steven

On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
> Just another note, we could just remove the p0_type/p0, and make p0,
> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
> test.c, it might be a possible solution.
>
> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>> Hi Felipe,
>>
>> Thanks very much for this.  At least there are no crashes. :)
>>
>> I've added just a little more debugging information to the test to
>> print out pointer addresses and sizes of things.  Could you by chance
>> run this test when you have a chance?
>>
>> Thanks!
>> steven
>>
>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>> Hi,
>>>
>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>
>>> The results are at [1]. Unfortunately, this only seems to work on
>>> x86-like architectures :(
>>>
>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>
>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>> Hi Felipe,
>>>>
>>>> Attached is a test file that illustrates the kinds of things that are
>>>> happening with the RTTI code in Csound.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> That's a good point, but I think we don't have to worry about the
>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>> for in the code.
>>>>>
>>>>> I'll see about writing up a test file and will reply once I have a
>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>> location of the type correctly.
>>>>>>
>>>>>> I'm not sure this assumption holds. Because if
>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>> will not align on the second element.
>>>>>>
>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>
>>>>>> Same as above here.
>>>>>>
>>>>>>
>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>> hold, I could build it on the following architectures:
>>>>>>
>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>
>>>>>>
>>>>>> Hopefully that is a wide enough test net.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-20 20:45
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
OK, result.log updated with new test program:

http://people.debian.org/~fsateler/testresults/result.log

On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
> Just to note, I built and ran the CsoundAndroidExamples project on my
> Nexus 4.  I did not experience any issues running the examples.  I
> suspect that the RTTI stuff may not be working correctly since the ARM
> compile failed in Felipe's tests.  I think then with the latest that
> Csound is in the same shape as it was before RTTI, and RTTI is only
> working on x86 based processors.  We can work on the RTTI stuff
> separately and it shouldn't interfere with any other work at this
> time.
>
> Thanks!
> steven
>
> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>> Just another note, we could just remove the p0_type/p0, and make p0,
>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>> test.c, it might be a possible solution.
>>
>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> Thanks very much for this.  At least there are no crashes. :)
>>>
>>> I've added just a little more debugging information to the test to
>>> print out pointer addresses and sizes of things.  Could you by chance
>>> run this test when you have a chance?
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>> Hi,
>>>>
>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>
>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>> x86-like architectures :(
>>>>
>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>
>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>> happening with the RTTI code in Csound.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>> for in the code.
>>>>>>
>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>> location of the type correctly.
>>>>>>>
>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>> will not align on the second element.
>>>>>>>
>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>
>>>>>>> Same as above here.
>>>>>>>
>>>>>>>
>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>> hold, I could build it on the following architectures:
>>>>>>>
>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>
>>>>>>>
>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Saludos,
>>>>>>> Felipe Sateler
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-21 00:23
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Attachmentstest.c  None  None  
Thanks Felipe!

>From what I can ascertain, all of the affected builds (armv7l, mips64,
ppc64, sparc64) are all big endian processors.  Also, the code for
handling padding and struct sizing is working. What's not working is
the type punning of the p0_type/p0 as a CS_VAR_MEM.

I've attached another revised test.c.  If you could run this again,
I'd very much appreciate it.  I tried to get Raspbian to run with
qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
see if I can get some c test code going on my Android phone too.

Thanks!
steven



On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
> OK, result.log updated with new test program:
>
> http://people.debian.org/~fsateler/testresults/result.log
>
> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>> Just to note, I built and ran the CsoundAndroidExamples project on my
>> Nexus 4.  I did not experience any issues running the examples.  I
>> suspect that the RTTI stuff may not be working correctly since the ARM
>> compile failed in Felipe's tests.  I think then with the latest that
>> Csound is in the same shape as it was before RTTI, and RTTI is only
>> working on x86 based processors.  We can work on the RTTI stuff
>> separately and it shouldn't interfere with any other work at this
>> time.
>>
>> Thanks!
>> steven
>>
>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>> test.c, it might be a possible solution.
>>>
>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>> Hi Felipe,
>>>>
>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>
>>>> I've added just a little more debugging information to the test to
>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>> run this test when you have a chance?
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>> Hi,
>>>>>
>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>
>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>> x86-like architectures :(
>>>>>
>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>
>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>> happening with the RTTI code in Csound.
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>> for in the code.
>>>>>>>
>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>> location of the type correctly.
>>>>>>>>
>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>> will not align on the second element.
>>>>>>>>
>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>
>>>>>>>> Same as above here.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>
>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>
>>>>>>>>
>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Saludos,
>>>>>>>> Felipe Sateler
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
Date2014-07-24 03:57
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Update: I managed to get a basic Android application setup with NDK
building a native lib for Arm.  I'm able to run the app and reproduce
the error behavior on my Nexus 4.  From reading the pointer addresses,
what happened is that one of the CS_TYPE* got packed with the char*
before it in that MOCK_CSOUND struct.  That offset things by four.
That assumption I made to cast that address as CS_VAR_MEM was
obviously in error.

Switching the p0_type/p0 stuff to just be CS_VAR_MEM seems to work
just fine on the Nexus 4.  I will look at modifying INSDS tomorrow to
have four CS_VAR_MEM fields instead of p0, p1, p2, p3, etc.  I will
test that on OSX and Android and will run the RTTI test csd on both.
If that works, I will push then test again on Windows.

On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
> Thanks Felipe!
>
> From what I can ascertain, all of the affected builds (armv7l, mips64,
> ppc64, sparc64) are all big endian processors.  Also, the code for
> handling padding and struct sizing is working. What's not working is
> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>
> I've attached another revised test.c.  If you could run this again,
> I'd very much appreciate it.  I tried to get Raspbian to run with
> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
> see if I can get some c test code going on my Android phone too.
>
> Thanks!
> steven
>
>
>
> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>> OK, result.log updated with new test program:
>>
>> http://people.debian.org/~fsateler/testresults/result.log
>>
>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>> Nexus 4.  I did not experience any issues running the examples.  I
>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>> compile failed in Felipe's tests.  I think then with the latest that
>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>> working on x86 based processors.  We can work on the RTTI stuff
>>> separately and it shouldn't interfere with any other work at this
>>> time.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>> test.c, it might be a possible solution.
>>>>
>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>
>>>>> I've added just a little more debugging information to the test to
>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>> run this test when you have a chance?
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>
>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>> x86-like architectures :(
>>>>>>
>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>> happening with the RTTI code in Csound.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>> Hi Felipe,
>>>>>>>>
>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>> for in the code.
>>>>>>>>
>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>> location of the type correctly.
>>>>>>>>>
>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>> will not align on the second element.
>>>>>>>>>
>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>
>>>>>>>>> Same as above here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>
>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Saludos,
>>>>>>>>> Felipe Sateler
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-24 16:11
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
Hi Steven,

I've been very busy this week, so I haven't been able to run the new
test program. I will as soon as I get some time. I have not forgotten
this!

On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
> Thanks Felipe!
>
> >From what I can ascertain, all of the affected builds (armv7l, mips64,
> ppc64, sparc64) are all big endian processors.  Also, the code for
> handling padding and struct sizing is working. What's not working is
> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>
> I've attached another revised test.c.  If you could run this again,
> I'd very much appreciate it.  I tried to get Raspbian to run with
> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
> see if I can get some c test code going on my Android phone too.
>
> Thanks!
> steven
>
>
>
> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>> OK, result.log updated with new test program:
>>
>> http://people.debian.org/~fsateler/testresults/result.log
>>
>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>> Nexus 4.  I did not experience any issues running the examples.  I
>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>> compile failed in Felipe's tests.  I think then with the latest that
>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>> working on x86 based processors.  We can work on the RTTI stuff
>>> separately and it shouldn't interfere with any other work at this
>>> time.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>> test.c, it might be a possible solution.
>>>>
>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>
>>>>> I've added just a little more debugging information to the test to
>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>> run this test when you have a chance?
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>
>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>> x86-like architectures :(
>>>>>>
>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>> happening with the RTTI code in Csound.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>> Hi Felipe,
>>>>>>>>
>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>> for in the code.
>>>>>>>>
>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>> location of the type correctly.
>>>>>>>>>
>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>> will not align on the second element.
>>>>>>>>>
>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>
>>>>>>>>> Same as above here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>
>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Saludos,
>>>>>>>>> Felipe Sateler
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-24 16:19
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Hi Felipe,

No worries, I don't think we need the compile test now that I was able
to reproduce on an ARM device. Thanks!

steven

On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
> Hi Steven,
>
> I've been very busy this week, so I haven't been able to run the new
> test program. I will as soon as I get some time. I have not forgotten
> this!
>
> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>> Thanks Felipe!
>>
>> >From what I can ascertain, all of the affected builds (armv7l, mips64,
>> ppc64, sparc64) are all big endian processors.  Also, the code for
>> handling padding and struct sizing is working. What's not working is
>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>
>> I've attached another revised test.c.  If you could run this again,
>> I'd very much appreciate it.  I tried to get Raspbian to run with
>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>> see if I can get some c test code going on my Android phone too.
>>
>> Thanks!
>> steven
>>
>>
>>
>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>> OK, result.log updated with new test program:
>>>
>>> http://people.debian.org/~fsateler/testresults/result.log
>>>
>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>> separately and it shouldn't interfere with any other work at this
>>>> time.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>> test.c, it might be a possible solution.
>>>>>
>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>
>>>>>> I've added just a little more debugging information to the test to
>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>> run this test when you have a chance?
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>
>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>> x86-like architectures :(
>>>>>>>
>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>> Hi Felipe,
>>>>>>>>
>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>> for in the code.
>>>>>>>>>
>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>
>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>> will not align on the second element.
>>>>>>>>>>
>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>
>>>>>>>>>> Same as above here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>
>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Saludos,
>>>>>>>>>> Felipe Sateler
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Saludos,
>>>>>>> Felipe Sateler
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 03:13
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
value, as I thought that made it easier to read around the codebase.

I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
the Android build on my Nexus 4).  I ran the runtime_type.csd to test
and RTTI worked on both desktop and phone. I think at this point we
should be good.

Thanks!
steven

On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
> Hi Felipe,
>
> No worries, I don't think we need the compile test now that I was able
> to reproduce on an ARM device. Thanks!
>
> steven
>
> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>> Hi Steven,
>>
>> I've been very busy this week, so I haven't been able to run the new
>> test program. I will as soon as I get some time. I have not forgotten
>> this!
>>
>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>> Thanks Felipe!
>>>
>>> >From what I can ascertain, all of the affected builds (armv7l, mips64,
>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>> handling padding and struct sizing is working. What's not working is
>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>
>>> I've attached another revised test.c.  If you could run this again,
>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>> see if I can get some c test code going on my Android phone too.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>>
>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>> OK, result.log updated with new test program:
>>>>
>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>
>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>> separately and it shouldn't interfere with any other work at this
>>>>> time.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>> test.c, it might be a possible solution.
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>
>>>>>>> I've added just a little more debugging information to the test to
>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>> run this test when you have a chance?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>
>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>> x86-like architectures :(
>>>>>>>>
>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>> Hi Felipe,
>>>>>>>>>>
>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>> for in the code.
>>>>>>>>>>
>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> steven
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>
>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>
>>>>>>>>>>> Same as above here.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>
>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Saludos,
>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Saludos,
>>>>>>>> Felipe Sateler
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 14:55
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
Sounds good. Will it need much (any) source code surgery for this?
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 25 Jul 2014, at 03:13, Steven Yi  wrote:

> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
> value, as I thought that made it easier to read around the codebase.
> 
> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
> and RTTI worked on both desktop and phone. I think at this point we
> should be good.
> 
> Thanks!
> steven
> 
> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
>> Hi Felipe,
>> 
>> No worries, I don't think we need the compile test now that I was able
>> to reproduce on an ARM device. Thanks!
>> 
>> steven
>> 
>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>>> Hi Steven,
>>> 
>>> I've been very busy this week, so I haven't been able to run the new
>>> test program. I will as soon as I get some time. I have not forgotten
>>> this!
>>> 
>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>>> Thanks Felipe!
>>>> 
>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>> handling padding and struct sizing is working. What's not working is
>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>> 
>>>> I've attached another revised test.c.  If you could run this again,
>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>> see if I can get some c test code going on my Android phone too.
>>>> 
>>>> Thanks!
>>>> steven
>>>> 
>>>> 
>>>> 
>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>>> OK, result.log updated with new test program:
>>>>> 
>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>> 
>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>> time.
>>>>>> 
>>>>>> Thanks!
>>>>>> steven
>>>>>> 
>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>> test.c, it might be a possible solution.
>>>>>>> 
>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>>> Hi Felipe,
>>>>>>>> 
>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>> 
>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>> run this test when you have a chance?
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>> 
>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>> 
>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>> x86-like architectures :(
>>>>>>>>> 
>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>> 
>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>>> Hi Felipe,
>>>>>>>>>> 
>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>> 
>>>>>>>>>> Thanks!
>>>>>>>>>> steven
>>>>>>>>>> 
>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>> 
>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>> for in the code.
>>>>>>>>>>> 
>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>> 
>>>>>>>>>>> Thanks!
>>>>>>>>>>> steven
>>>>>>>>>>> 
>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>> 
>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>> 
>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> 
>>>>>>>>>>>> Saludos,
>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>> 
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>> 
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 
>>>>>>>>> Saludos,
>>>>>>>>> Felipe Sateler
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Saludos,
>>> Felipe Sateler
>>> 
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 15:34
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
I think I got all the changes already (wasn't bad at all really).  The
changes are visible here:

https://github.com/csound/csound/commit/a7fa6d3cc6a485d057eceb889279494dbac5680a

One thing we could do from here now is remove the use of SSTRCOD in
opcodes, as well as XINCOD and XOUTCOD.  These are sort of "hacks" IMO
to do what RTTI does, which is to get the type of the argument. The
changes I see are:

1. Remove setting of XINCOD and XOUTCOD
2. Replace use of XINCOD and XOUTCOD with lookup via RTTI
3. SSTRCOD is still useful at the moment for pfields, but we can move
it's up architecturally. What we can do is in the code that reads
pfields from an EVTBLK and sets it on the INSDS, is to check SSTRCOD
there, then just directly set the STRINGDAT as the pfield value in the
INSDS.  Opcodes can then use RTTI to check if the arg is a string or
constant.  Eventually we can remove SSTRCOD as a whole if we alter
EVTBLK to store not just an array of MYFLT, but and array of
CS_VAR_MEM (similarly to what I did for INSDS).

To do the above, we would also need a utility function to lookup the
type for an arg.  The print_type_opcode function in OOps/str_ops.c has
the relevant code:

print_type_opcode(CSOUND* csound, PRINT_TYPE_OP* p) {
    char* ptr = (char*)p->inVar;

    CS_TYPE* varType = *(CS_TYPE**)(ptr - CS_VAR_TYPE_OFFSET);
    csound->Message(csound, "Variable Type: %s\n", varType->varTypeName);

    return OK;
}

The first two lines of code is essentially what we should move into an
API function, something like:

CS_TYPE* csoundGetTypeForArg(void* argPtr);

or maybe csoundGetTypeForVariable, or some other name.

I think getting rid of XINCOD, XOUTCOD, and other things could make
the code base a little easier to read and understand.  Also, we should
probably do this now for the next release as this would also be a
breaking change, and we might as well break things all at once. :)

I hadn't thought of this work until just now. I was planning to get
started on Parser3 as my next project.  If you'd like to take a stab
at it, that'd be great, but I could also look at this next and move on
to Parser3 afterwards.

Thanks!
steven

On Fri, Jul 25, 2014 at 9:55 AM, Victor Lazzarini
 wrote:
> Sounds good. Will it need much (any) source code surgery for this?
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 25 Jul 2014, at 03:13, Steven Yi  wrote:
>
>> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
>> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
>> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
>> value, as I thought that made it easier to read around the codebase.
>>
>> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
>> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
>> and RTTI worked on both desktop and phone. I think at this point we
>> should be good.
>>
>> Thanks!
>> steven
>>
>> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> No worries, I don't think we need the compile test now that I was able
>>> to reproduce on an ARM device. Thanks!
>>>
>>> steven
>>>
>>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>>>> Hi Steven,
>>>>
>>>> I've been very busy this week, so I haven't been able to run the new
>>>> test program. I will as soon as I get some time. I have not forgotten
>>>> this!
>>>>
>>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>>>> Thanks Felipe!
>>>>>
>>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>>> handling padding and struct sizing is working. What's not working is
>>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>>>
>>>>> I've attached another revised test.c.  If you could run this again,
>>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>>> see if I can get some c test code going on my Android phone too.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>>>> OK, result.log updated with new test program:
>>>>>>
>>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>>>
>>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>>> time.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>>> test.c, it might be a possible solution.
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>>>
>>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>>> run this test when you have a chance?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>>>
>>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>>> x86-like architectures :(
>>>>>>>>>>
>>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>
>>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> steven
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>
>>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>>> for in the code.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> steven
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>>>
>>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Saludos,
>>>>>>>>>> Felipe Sateler
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 15:40
FromVictor Lazzarini
SubjectRe: [Cs-dev] Csound crashing
Do you have an example of the XINCOD/XOUTCOD replacement? With that, it
would be just a matter of legwork. I agree we should do it now.

Regards
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 25 Jul 2014, at 15:34, Steven Yi  wrote:

> I think I got all the changes already (wasn't bad at all really).  The
> changes are visible here:
> 
> https://github.com/csound/csound/commit/a7fa6d3cc6a485d057eceb889279494dbac5680a
> 
> One thing we could do from here now is remove the use of SSTRCOD in
> opcodes, as well as XINCOD and XOUTCOD.  These are sort of "hacks" IMO
> to do what RTTI does, which is to get the type of the argument. The
> changes I see are:
> 
> 1. Remove setting of XINCOD and XOUTCOD
> 2. Replace use of XINCOD and XOUTCOD with lookup via RTTI
> 3. SSTRCOD is still useful at the moment for pfields, but we can move
> it's up architecturally. What we can do is in the code that reads
> pfields from an EVTBLK and sets it on the INSDS, is to check SSTRCOD
> there, then just directly set the STRINGDAT as the pfield value in the
> INSDS.  Opcodes can then use RTTI to check if the arg is a string or
> constant.  Eventually we can remove SSTRCOD as a whole if we alter
> EVTBLK to store not just an array of MYFLT, but and array of
> CS_VAR_MEM (similarly to what I did for INSDS).
> 
> To do the above, we would also need a utility function to lookup the
> type for an arg.  The print_type_opcode function in OOps/str_ops.c has
> the relevant code:
> 
> print_type_opcode(CSOUND* csound, PRINT_TYPE_OP* p) {
>    char* ptr = (char*)p->inVar;
> 
>    CS_TYPE* varType = *(CS_TYPE**)(ptr - CS_VAR_TYPE_OFFSET);
>    csound->Message(csound, "Variable Type: %s\n", varType->varTypeName);
> 
>    return OK;
> }
> 
> The first two lines of code is essentially what we should move into an
> API function, something like:
> 
> CS_TYPE* csoundGetTypeForArg(void* argPtr);
> 
> or maybe csoundGetTypeForVariable, or some other name.
> 
> I think getting rid of XINCOD, XOUTCOD, and other things could make
> the code base a little easier to read and understand.  Also, we should
> probably do this now for the next release as this would also be a
> breaking change, and we might as well break things all at once. :)
> 
> I hadn't thought of this work until just now. I was planning to get
> started on Parser3 as my next project.  If you'd like to take a stab
> at it, that'd be great, but I could also look at this next and move on
> to Parser3 afterwards.
> 
> Thanks!
> steven
> 
> On Fri, Jul 25, 2014 at 9:55 AM, Victor Lazzarini
>  wrote:
>> Sounds good. Will it need much (any) source code surgery for this?
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 25 Jul 2014, at 03:13, Steven Yi  wrote:
>> 
>>> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
>>> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
>>> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
>>> value, as I thought that made it easier to read around the codebase.
>>> 
>>> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
>>> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
>>> and RTTI worked on both desktop and phone. I think at this point we
>>> should be good.
>>> 
>>> Thanks!
>>> steven
>>> 
>>> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
>>>> Hi Felipe,
>>>> 
>>>> No worries, I don't think we need the compile test now that I was able
>>>> to reproduce on an ARM device. Thanks!
>>>> 
>>>> steven
>>>> 
>>>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>>>>> Hi Steven,
>>>>> 
>>>>> I've been very busy this week, so I haven't been able to run the new
>>>>> test program. I will as soon as I get some time. I have not forgotten
>>>>> this!
>>>>> 
>>>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>>>>> Thanks Felipe!
>>>>>> 
>>>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>>>> handling padding and struct sizing is working. What's not working is
>>>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>>>> 
>>>>>> I've attached another revised test.c.  If you could run this again,
>>>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>>>> see if I can get some c test code going on my Android phone too.
>>>>>> 
>>>>>> Thanks!
>>>>>> steven
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>>>>> OK, result.log updated with new test program:
>>>>>>> 
>>>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>>>> 
>>>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>>>> time.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>> 
>>>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>>>> test.c, it might be a possible solution.
>>>>>>>>> 
>>>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>>>>> Hi Felipe,
>>>>>>>>>> 
>>>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>>>> 
>>>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>>>> run this test when you have a chance?
>>>>>>>>>> 
>>>>>>>>>> Thanks!
>>>>>>>>>> steven
>>>>>>>>>> 
>>>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>>>> 
>>>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>>>> x86-like architectures :(
>>>>>>>>>>> 
>>>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>>> 
>>>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>> 
>>>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> steven
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>>>> for in the code.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> steven
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>> 
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> 
>>>>>>>>>>> Saludos,
>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>> 
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Saludos,
>>>>>>> Felipe Sateler
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 15:42
FromMichael Gogins
SubjectRe: [Cs-dev] Csound crashing
AttachmentsNone  None  
I think doing this now is a very good idea.

Regards,
Mike


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


On Fri, Jul 25, 2014 at 10:34 AM, Steven Yi <stevenyi@gmail.com> wrote:
I think I got all the changes already (wasn't bad at all really).  The
changes are visible here:

https://github.com/csound/csound/commit/a7fa6d3cc6a485d057eceb889279494dbac5680a

One thing we could do from here now is remove the use of SSTRCOD in
opcodes, as well as XINCOD and XOUTCOD.  These are sort of "hacks" IMO
to do what RTTI does, which is to get the type of the argument. The
changes I see are:

1. Remove setting of XINCOD and XOUTCOD
2. Replace use of XINCOD and XOUTCOD with lookup via RTTI
3. SSTRCOD is still useful at the moment for pfields, but we can move
it's up architecturally. What we can do is in the code that reads
pfields from an EVTBLK and sets it on the INSDS, is to check SSTRCOD
there, then just directly set the STRINGDAT as the pfield value in the
INSDS.  Opcodes can then use RTTI to check if the arg is a string or
constant.  Eventually we can remove SSTRCOD as a whole if we alter
EVTBLK to store not just an array of MYFLT, but and array of
CS_VAR_MEM (similarly to what I did for INSDS).

To do the above, we would also need a utility function to lookup the
type for an arg.  The print_type_opcode function in OOps/str_ops.c has
the relevant code:

print_type_opcode(CSOUND* csound, PRINT_TYPE_OP* p) {
    char* ptr = (char*)p->inVar;

    CS_TYPE* varType = *(CS_TYPE**)(ptr - CS_VAR_TYPE_OFFSET);
    csound->Message(csound, "Variable Type: %s\n", varType->varTypeName);

    return OK;
}

The first two lines of code is essentially what we should move into an
API function, something like:

CS_TYPE* csoundGetTypeForArg(void* argPtr);

or maybe csoundGetTypeForVariable, or some other name.

I think getting rid of XINCOD, XOUTCOD, and other things could make
the code base a little easier to read and understand.  Also, we should
probably do this now for the next release as this would also be a
breaking change, and we might as well break things all at once. :)

I hadn't thought of this work until just now. I was planning to get
started on Parser3 as my next project.  If you'd like to take a stab
at it, that'd be great, but I could also look at this next and move on
to Parser3 afterwards.

Thanks!
steven

On Fri, Jul 25, 2014 at 9:55 AM, Victor Lazzarini
<Victor.Lazzarini@nuim.ie> wrote:
> Sounds good. Will it need much (any) source code surgery for this?
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 25 Jul 2014, at 03:13, Steven Yi <stevenyi@gmail.com> wrote:
>
>> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
>> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
>> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
>> value, as I thought that made it easier to read around the codebase.
>>
>> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
>> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
>> and RTTI worked on both desktop and phone. I think at this point we
>> should be good.
>>
>> Thanks!
>> steven
>>
>> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>> Hi Felipe,
>>>
>>> No worries, I don't think we need the compile test now that I was able
>>> to reproduce on an ARM device. Thanks!
>>>
>>> steven
>>>
>>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler <fsateler@gmail.com> wrote:
>>>> Hi Steven,
>>>>
>>>> I've been very busy this week, so I haven't been able to run the new
>>>> test program. I will as soon as I get some time. I have not forgotten
>>>> this!
>>>>
>>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>> Thanks Felipe!
>>>>>
>>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>>> handling padding and struct sizing is working. What's not working is
>>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>>>
>>>>> I've attached another revised test.c.  If you could run this again,
>>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>>> see if I can get some c test code going on my Android phone too.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler <fsateler@gmail.com> wrote:
>>>>>> OK, result.log updated with new test program:
>>>>>>
>>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>>>
>>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>>> time.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>>> test.c, it might be a possible solution.
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>>>
>>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>>> run this test when you have a chance?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler <fsateler@gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>>>
>>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>>> x86-like architectures :(
>>>>>>>>>>
>>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>
>>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> steven
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>
>>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>>> for in the code.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> steven
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler <fsateler@gmail.com> wrote:
>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>>>
>>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Saludos,
>>>>>>>>>> Felipe Sateler
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Date2014-07-25 15:52
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
Let me see if I can do an example opcode conversion now.  I'll report
back momentarily. (hopefully!)

On Fri, Jul 25, 2014 at 10:40 AM, Victor Lazzarini
 wrote:
> Do you have an example of the XINCOD/XOUTCOD replacement? With that, it
> would be just a matter of legwork. I agree we should do it now.
>
> Regards
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 25 Jul 2014, at 15:34, Steven Yi  wrote:
>
>> I think I got all the changes already (wasn't bad at all really).  The
>> changes are visible here:
>>
>> https://github.com/csound/csound/commit/a7fa6d3cc6a485d057eceb889279494dbac5680a
>>
>> One thing we could do from here now is remove the use of SSTRCOD in
>> opcodes, as well as XINCOD and XOUTCOD.  These are sort of "hacks" IMO
>> to do what RTTI does, which is to get the type of the argument. The
>> changes I see are:
>>
>> 1. Remove setting of XINCOD and XOUTCOD
>> 2. Replace use of XINCOD and XOUTCOD with lookup via RTTI
>> 3. SSTRCOD is still useful at the moment for pfields, but we can move
>> it's up architecturally. What we can do is in the code that reads
>> pfields from an EVTBLK and sets it on the INSDS, is to check SSTRCOD
>> there, then just directly set the STRINGDAT as the pfield value in the
>> INSDS.  Opcodes can then use RTTI to check if the arg is a string or
>> constant.  Eventually we can remove SSTRCOD as a whole if we alter
>> EVTBLK to store not just an array of MYFLT, but and array of
>> CS_VAR_MEM (similarly to what I did for INSDS).
>>
>> To do the above, we would also need a utility function to lookup the
>> type for an arg.  The print_type_opcode function in OOps/str_ops.c has
>> the relevant code:
>>
>> print_type_opcode(CSOUND* csound, PRINT_TYPE_OP* p) {
>>    char* ptr = (char*)p->inVar;
>>
>>    CS_TYPE* varType = *(CS_TYPE**)(ptr - CS_VAR_TYPE_OFFSET);
>>    csound->Message(csound, "Variable Type: %s\n", varType->varTypeName);
>>
>>    return OK;
>> }
>>
>> The first two lines of code is essentially what we should move into an
>> API function, something like:
>>
>> CS_TYPE* csoundGetTypeForArg(void* argPtr);
>>
>> or maybe csoundGetTypeForVariable, or some other name.
>>
>> I think getting rid of XINCOD, XOUTCOD, and other things could make
>> the code base a little easier to read and understand.  Also, we should
>> probably do this now for the next release as this would also be a
>> breaking change, and we might as well break things all at once. :)
>>
>> I hadn't thought of this work until just now. I was planning to get
>> started on Parser3 as my next project.  If you'd like to take a stab
>> at it, that'd be great, but I could also look at this next and move on
>> to Parser3 afterwards.
>>
>> Thanks!
>> steven
>>
>> On Fri, Jul 25, 2014 at 9:55 AM, Victor Lazzarini
>>  wrote:
>>> Sounds good. Will it need much (any) source code surgery for this?
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 25 Jul 2014, at 03:13, Steven Yi  wrote:
>>>
>>>> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
>>>> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
>>>> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
>>>> value, as I thought that made it easier to read around the codebase.
>>>>
>>>> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
>>>> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
>>>> and RTTI worked on both desktop and phone. I think at this point we
>>>> should be good.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> No worries, I don't think we need the compile test now that I was able
>>>>> to reproduce on an ARM device. Thanks!
>>>>>
>>>>> steven
>>>>>
>>>>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>>>>>> Hi Steven,
>>>>>>
>>>>>> I've been very busy this week, so I haven't been able to run the new
>>>>>> test program. I will as soon as I get some time. I have not forgotten
>>>>>> this!
>>>>>>
>>>>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>>>>>> Thanks Felipe!
>>>>>>>
>>>>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>>>>> handling padding and struct sizing is working. What's not working is
>>>>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>>>>>
>>>>>>> I've attached another revised test.c.  If you could run this again,
>>>>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>>>>> see if I can get some c test code going on my Android phone too.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>>>>>> OK, result.log updated with new test program:
>>>>>>>>
>>>>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>
>>>>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>>>>> test.c, it might be a possible solution.
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>
>>>>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>>>>>
>>>>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>>>>> run this test when you have a chance?
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> steven
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>>>>>
>>>>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>>>>> x86-like architectures :(
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> steven
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>>>>> for in the code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> steven
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> Saludos,
>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Saludos,
>>>>>>>> Felipe Sateler
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-25 16:14
FromSteven Yi
SubjectRe: [Cs-dev] Csound crashing
I've pushed a commit with an example of how to change code from using
XINCOD and XINARGX macros to using RTTI:

https://github.com/csound/csound/commit/d85532e412e8f3f329326cb16359dbc3dcc266c4

I added the csoundGetTypeForArg function just in that file as well as
added an IS_ASIG_ARG macro to condense the code a bit.  (Those two
should be moved elsewhere, but I have to take care of some other
things so just put it there for now.  Please feel free to move.)

With those two functions, the code changes from:

p->ampcod = (XINARG1) ? 1 : 0;
p->cpscod = (XINARG2) ? 1 : 0;

to:

p->ampcod = IS_ASIG_ARG(p->xamp) ? 1 : 0;
p->cpscod = IS_ASIG_ARG(p->xcps) ? 1 : 0;

I think the code actually reads better as XINARGX macros depends on
the developer having to remember which argument is what by index.
Here, the developer can just say "is this arg pointer an asig?".

One thing to note, args from pfields currently come in as
CS_VAR_TYPE_P.  This needs to change for us to get rid of SSTRCOD, but
should be alright for us getting rid of XINCOD and XOUTCOD.  Those two
latter values are only used to check if an argument is an asig or not,
so if the value comes in from a pfield, using RTTI still preserves the
same logic of checking if it is an asig or not.

I tested here only on OSX.  I imagine we should test on Android and
elsewhere just in case, but since the runtime_type.csd passed on
Android I feel okay with this.

Feedback welcome!
steven

On Fri, Jul 25, 2014 at 10:52 AM, Steven Yi  wrote:
> Let me see if I can do an example opcode conversion now.  I'll report
> back momentarily. (hopefully!)
>
> On Fri, Jul 25, 2014 at 10:40 AM, Victor Lazzarini
>  wrote:
>> Do you have an example of the XINCOD/XOUTCOD replacement? With that, it
>> would be just a matter of legwork. I agree we should do it now.
>>
>> Regards
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>>
>>
>>
>>
>> On 25 Jul 2014, at 15:34, Steven Yi  wrote:
>>
>>> I think I got all the changes already (wasn't bad at all really).  The
>>> changes are visible here:
>>>
>>> https://github.com/csound/csound/commit/a7fa6d3cc6a485d057eceb889279494dbac5680a
>>>
>>> One thing we could do from here now is remove the use of SSTRCOD in
>>> opcodes, as well as XINCOD and XOUTCOD.  These are sort of "hacks" IMO
>>> to do what RTTI does, which is to get the type of the argument. The
>>> changes I see are:
>>>
>>> 1. Remove setting of XINCOD and XOUTCOD
>>> 2. Replace use of XINCOD and XOUTCOD with lookup via RTTI
>>> 3. SSTRCOD is still useful at the moment for pfields, but we can move
>>> it's up architecturally. What we can do is in the code that reads
>>> pfields from an EVTBLK and sets it on the INSDS, is to check SSTRCOD
>>> there, then just directly set the STRINGDAT as the pfield value in the
>>> INSDS.  Opcodes can then use RTTI to check if the arg is a string or
>>> constant.  Eventually we can remove SSTRCOD as a whole if we alter
>>> EVTBLK to store not just an array of MYFLT, but and array of
>>> CS_VAR_MEM (similarly to what I did for INSDS).
>>>
>>> To do the above, we would also need a utility function to lookup the
>>> type for an arg.  The print_type_opcode function in OOps/str_ops.c has
>>> the relevant code:
>>>
>>> print_type_opcode(CSOUND* csound, PRINT_TYPE_OP* p) {
>>>    char* ptr = (char*)p->inVar;
>>>
>>>    CS_TYPE* varType = *(CS_TYPE**)(ptr - CS_VAR_TYPE_OFFSET);
>>>    csound->Message(csound, "Variable Type: %s\n", varType->varTypeName);
>>>
>>>    return OK;
>>> }
>>>
>>> The first two lines of code is essentially what we should move into an
>>> API function, something like:
>>>
>>> CS_TYPE* csoundGetTypeForArg(void* argPtr);
>>>
>>> or maybe csoundGetTypeForVariable, or some other name.
>>>
>>> I think getting rid of XINCOD, XOUTCOD, and other things could make
>>> the code base a little easier to read and understand.  Also, we should
>>> probably do this now for the next release as this would also be a
>>> breaking change, and we might as well break things all at once. :)
>>>
>>> I hadn't thought of this work until just now. I was planning to get
>>> started on Parser3 as my next project.  If you'd like to take a stab
>>> at it, that'd be great, but I could also look at this next and move on
>>> to Parser3 afterwards.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, Jul 25, 2014 at 9:55 AM, Victor Lazzarini
>>>  wrote:
>>>> Sounds good. Will it need much (any) source code surgery for this?
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> On 25 Jul 2014, at 03:13, Steven Yi  wrote:
>>>>
>>>>> Update: I've redone INSDS to use CS_VAR_MEM for pfields 0-3.  I had to
>>>>> change code to use "ip->p3.value" instead of "ip->p3" as p3 and others
>>>>> are CS_VAR_MEM.  I also changed CS_VAR_MEM to rename memBlock to
>>>>> value, as I thought that made it easier to read around the codebase.
>>>>>
>>>>> I built and tested on OSX (i386 and x86_64) as well as on ARMv7 (using
>>>>> the Android build on my Nexus 4).  I ran the runtime_type.csd to test
>>>>> and RTTI worked on both desktop and phone. I think at this point we
>>>>> should be good.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> No worries, I don't think we need the compile test now that I was able
>>>>>> to reproduce on an ARM device. Thanks!
>>>>>>
>>>>>> steven
>>>>>>
>>>>>> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>>>>>>> Hi Steven,
>>>>>>>
>>>>>>> I've been very busy this week, so I haven't been able to run the new
>>>>>>> test program. I will as soon as I get some time. I have not forgotten
>>>>>>> this!
>>>>>>>
>>>>>>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>>>>>>> Thanks Felipe!
>>>>>>>>
>>>>>>>>> From what I can ascertain, all of the affected builds (armv7l, mips64,
>>>>>>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>>>>>>> handling padding and struct sizing is working. What's not working is
>>>>>>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>>>>>>
>>>>>>>> I've attached another revised test.c.  If you could run this again,
>>>>>>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>>>>>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>>>>>>> see if I can get some c test code going on my Android phone too.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>>>>>>> OK, result.log updated with new test program:
>>>>>>>>>
>>>>>>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>
>>>>>>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>>>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>>>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>>>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>>>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>>>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>>>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>>>>>>> separately and it shouldn't interfere with any other work at this
>>>>>>>>>> time.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> steven
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>>>>>>> test.c, it might be a possible solution.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>>>>>>
>>>>>>>>>>>> I've added just a little more debugging information to the test to
>>>>>>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>>>>>>> run this test when you have a chance?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> steven
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>>>>>>> x86-like architectures :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> steven
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>>>>>>> Hi Felipe,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>>>>>>> for in the code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>> steven
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Same as above here.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Saludos,
>>>>>>>>> Felipe Sateler
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Saludos,
>>>>>>> Felipe Sateler
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
Date2014-07-26 17:54
FromFelipe Sateler
SubjectRe: [Cs-dev] Csound crashing
OK, I will not try it then.

Saludos

On Thu, Jul 24, 2014 at 11:19 AM, Steven Yi  wrote:
> Hi Felipe,
>
> No worries, I don't think we need the compile test now that I was able
> to reproduce on an ARM device. Thanks!
>
> steven
>
> On Thu, Jul 24, 2014 at 11:11 AM, Felipe Sateler  wrote:
>> Hi Steven,
>>
>> I've been very busy this week, so I haven't been able to run the new
>> test program. I will as soon as I get some time. I have not forgotten
>> this!
>>
>> On Sun, Jul 20, 2014 at 7:23 PM, Steven Yi  wrote:
>>> Thanks Felipe!
>>>
>>> >From what I can ascertain, all of the affected builds (armv7l, mips64,
>>> ppc64, sparc64) are all big endian processors.  Also, the code for
>>> handling padding and struct sizing is working. What's not working is
>>> the type punning of the p0_type/p0 as a CS_VAR_MEM.
>>>
>>> I've attached another revised test.c.  If you could run this again,
>>> I'd very much appreciate it.  I tried to get Raspbian to run with
>>> qemu-system-arm earlier on OSX but that didn't work out at all.  I'll
>>> see if I can get some c test code going on my Android phone too.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>>
>>> On Sun, Jul 20, 2014 at 3:45 PM, Felipe Sateler  wrote:
>>>> OK, result.log updated with new test program:
>>>>
>>>> http://people.debian.org/~fsateler/testresults/result.log
>>>>
>>>> On Sun, Jul 20, 2014 at 12:09 PM, Steven Yi  wrote:
>>>>> Just to note, I built and ran the CsoundAndroidExamples project on my
>>>>> Nexus 4.  I did not experience any issues running the examples.  I
>>>>> suspect that the RTTI stuff may not be working correctly since the ARM
>>>>> compile failed in Felipe's tests.  I think then with the latest that
>>>>> Csound is in the same shape as it was before RTTI, and RTTI is only
>>>>> working on x86 based processors.  We can work on the RTTI stuff
>>>>> separately and it shouldn't interfere with any other work at this
>>>>> time.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Sat, Jul 19, 2014 at 9:10 PM, Steven Yi  wrote:
>>>>>> Just another note, we could just remove the p0_type/p0, and make p0,
>>>>>> p1, p2, and p3 all CS_VAR_MEM's.  Depending on the information in the
>>>>>> test.c, it might be a possible solution.
>>>>>>
>>>>>> On Sat, Jul 19, 2014 at 8:56 PM, Steven Yi  wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> Thanks very much for this.  At least there are no crashes. :)
>>>>>>>
>>>>>>> I've added just a little more debugging information to the test to
>>>>>>> print out pointer addresses and sizes of things.  Could you by chance
>>>>>>> run this test when you have a chance?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> On Sat, Jul 19, 2014 at 8:24 PM, Felipe Sateler  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I ran the tests on several platforms (I didnt have access to all of them).
>>>>>>>>
>>>>>>>> The results are at [1]. Unfortunately, this only seems to work on
>>>>>>>> x86-like architectures :(
>>>>>>>>
>>>>>>>> [1] http://people.debian.org/~fsateler/testresults/result.log
>>>>>>>>
>>>>>>>> On Sat, Jul 19, 2014 at 6:42 PM, Steven Yi  wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> Attached is a test file that illustrates the kinds of things that are
>>>>>>>>> happening with the RTTI code in Csound.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>> On Sat, Jul 19, 2014 at 12:05 PM, Steven Yi  wrote:
>>>>>>>>>> Hi Felipe,
>>>>>>>>>>
>>>>>>>>>> That's a good point, but I think we don't have to worry about the
>>>>>>>>>> memory after the CS_TYPE. In the code, when CS_VAR_MEM is used like an
>>>>>>>>>> array, then the code is done where it is allocating CS_VAR_MEM's
>>>>>>>>>> as-is, or aligns over the p0_type/p0 stuff in INSDS. In the case where
>>>>>>>>>> the memBlock is actually larger than than the sizeof(MYFLT), the
>>>>>>>>>> CS_VAR_MEM is used in the global var pool, where it is accessed via
>>>>>>>>>> csVar->memBlock.  That leaves the only concern being the padding
>>>>>>>>>> between CS_TYPE* and MYFLT in the struct, which I think is accounted
>>>>>>>>>> for in the code.
>>>>>>>>>>
>>>>>>>>>> I'll see about writing up a test file and will reply once I have a
>>>>>>>>>> chance (will be later tonight as I have to head out for the day).
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> steven
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 19, 2014 at 11:20 AM, Felipe Sateler  wrote:
>>>>>>>>>>> On Sat, Jul 19, 2014 at 10:22 AM, Steven Yi  wrote:
>>>>>>>>>>>> Update: the change using calculations of sizeof(CS_VAR_MEM) seem to
>>>>>>>>>>>> work.  I have tested with OSX (both i386 and x86_64 builds), and on
>>>>>>>>>>>> Windows.  The path I took was to take into account how much space was
>>>>>>>>>>>> used for CS_VAR_MEM's varType member, including padding, to calculate
>>>>>>>>>>>> based on sizeof(CS_VAR_MEM) - sizeof(MYFLT).  The assumption is that
>>>>>>>>>>>> because CS_VAR_MEM has two members, CS_TYPE* varMem and MYFLT
>>>>>>>>>>>> memBlock, then subtracting sizeof MYFLT would then give the full
>>>>>>>>>>>> memory size used by varMem + any padding.  That allows to then use
>>>>>>>>>>>> that calculated size to do pointer arithmetic via char* to get the
>>>>>>>>>>>> location of the type correctly.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure this assumption holds. Because if
>>>>>>>>>>> (sizeof(CS_TYPE*)+cs_type_padding + sizeof(MYFLT) + 1) is not aligned,
>>>>>>>>>>> the compiler needs to  add some padding, otherwise a dynamic array
>>>>>>>>>>> malloc'ed to n*(sizeof(CS_TYPE*) + cs_type_padding + sizeof(MYFLT))
>>>>>>>>>>> will not align on the second element.
>>>>>>>>>>>
>>>>>>>>>>>> Also, I was allocating CS_VAR_MEM's manually in some places as
>>>>>>>>>>>> sizeof(CS_TYPE*) + var->memBlockSize.  That would not have accounted
>>>>>>>>>>>> for any padding, so the calculation is now sizeof(CS_VAR_MEM) -
>>>>>>>>>>>> sizeof(MYFLT) + var->memBlockSize.
>>>>>>>>>>>
>>>>>>>>>>> Same as above here.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm thinking we could leverage the debian infrastructure to test this.
>>>>>>>>>>> If you can provide a test program that fails if the assumption doesn't
>>>>>>>>>>> hold, I could build it on the following architectures:
>>>>>>>>>>>
>>>>>>>>>>> armel armhf avr32 hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
>>>>>>>>>>> mipsel powerpc ppc64el s390x sh4 sparc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hopefully that is a wide enough test net.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Saludos,
>>>>>>>>>>> Felipe Sateler
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Saludos,
>>>>>>>> Felipe Sateler
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>>>>> Code Sight - the same software that powers the world's largest code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net