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@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@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@urbanstew.orgwrote:

...

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