[PD] Strange behavior using custom external

[Charles Z Henry]

The difference probably indicates that something is going on in your
_setup() function.  Once you've loaded a class in a patch, it stays in
memory.  If you close the patch, and open another patch without the class,
you may still see the effects---but if you close pd, and reopen without
using the class, you should not see the effects at all.

The backtrace shows a seg fault from calls in "binbuf_eval", which is the
code related to parsing and loading a patch.  You might just have passed a
struct as an argument, where it's expected to be an element of that struct.

Although.... pointer type mismatches will definitely throw a compiler
warning you should have seen already.  Would you post the _setup() function?

Chuck






On Thu, Feb 27, 2014 at 1:09 PM, Robert Esler <robert at urbanstew.org> wrote:

>
> Hi Chuck,
>   If I create another patch w/o the external I don't get this behavior at
> all.  Though if I create the patch w/ the external then delete it, save it
> and open it, there have been times where the behavior returns w/o the
> external.
>   I'll go through my pd object code again.  As you mention there could be
> symbol pointer that is not accessed or allocated correctly.
> -Rob
>
>
> On Feb 26, 2014, at 4:09 PM, Charles Z Henry <czhenry at gmail.com> wrote:
>
> Hi Robert,
>
> Just to clarify--have you also observed the error in any patches where you
> have not loaded the external?
>
> For example, if you take your patch, remove the external and save as
> "test.pd", will the word "tempo" appear correctly and without replacement?
>
> This sounds to me like a mismatched type, like a symbol pointer "foo"
> being used in place of a string like "foo->s_name" ... but I'm confused as
> to how that's occurring inside the text of a message box (not my best
> subject anyhow)
>
> Chuck
>
>
>
>
>
> On Wed, Feb 26, 2014 at 4:22 PM, Robert Esler <robert at urbanstew.org>wrote:
>
>> Hello everyone,
>>   I'm having a strange issue with a custom external built using C++.
>>  When using my external in Pd I send it "set" commands using a message box
>> to change internal parameters, e.g [set tempo $1(
>>   The strange behavior is as follows:
>>    1)  Sometimes when opening the patch the word "tempo" as referenced
>> above gets changed to some nonsensical characters or is missing altogether.
>>  So my message looks like [set ðLﾸ $1( or [set $1(, even though it was
>> saved as [set tempo $1(.
>>    2)  When the behavior above does not occur (e.g #1) and the message is
>> preserved upon opening, it only will work as written once then the second
>> time the message is nonsense again but does not actually display as having
>> changed.  So the GUI still reads [set tempo $1( but actually prints to the
>> Pd window as: print: set ðLﾸ 140.
>>    3)  At times when running my object, after #2 has happened, Pd crashes
>> and leaves a trace to:
>>
>> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes: KERN_INVALID_ADDRESS at 0x00000000100b1a6a
>>
>> VM Regions Near 0x100b1a6a:
>>     __LINKEDIT             00000000080a4000-00000000080a5000 [    4K]
>> r--/rwx SM=COW
>>  /Applications/Pd-extended.app/Contents/Resources/extra/pddp/pddplink.pd_darwin
>> -->
>>     __TEXT                 0000000070000000-000000007015f000 [ 1404K]
>> r-x/rwx SM=COW
>>  /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
>>
>>
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   libsystem_c.dylib             0x903833f0 strcmp + 80
>> 1   pdextended                     0x0001c493 gatom_key + 305
>> 2   pdextended                     0x000386cf canvas_key + 1659
>> 3   pdextended                     0x000540b0 pd_typedmess + 740
>> 4   pdextended                     0x00054107 pd_typedmess + 827
>> 5   pdextended                     0x00058394 binbuf_eval + 1224
>> 6   pdextended                     0x0006255c socketreceiver_read + 1734
>> 7   pdextended                     0x0006111c sys_domicrosleep + 381
>> 8   pdextended                     0x000611a8 sys_microsleep + 19
>> 9   pdextended                     0x0005e413 m_mainloop + 989
>> 10  pdextended                     0x00060e4b sys_main + 2909
>> 11  pdextended                     0x00002172 _start + 216
>> 12  pdextended                     0x00002099 start + 41
>>
>> -----------
>>
>> Right now I'm using Pd-extended 42.5, Mac OS X 10.8.5
>>
>> I'm happy to supply more code, examples, details, etc. if someone can
>> help.
>> Much appreciated,
>> Rob
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140227/8bc5edc1/attachment.htm>