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 <rob...@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 <czhe...@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 <rob...@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@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
