plugdata-team
Crash at standalone opening - Incorrect checksum for freed object 0x15b02ae
I occasionally get this error when opening PlugData on MacOS:
Got this readout in terminal when opening the program:
2025-07-10 06:58:19.679 PlugData[5473:35640] +[IMKClient subclass]: chose IMKClient_Modern 2025-07-10 06:58:19.679 PlugData[5473:35640] +[IMKInputSession subclass]: chose IMKInputSession_Modern PlugData(5473,0x1f51a0840) malloc: Incorrect checksum for freed object 0x15b02ae00: probably modified after being freed. Corrupt value: 0x0 PlugData(5473,0x1f51a0840) malloc: *** set a breakpoint in malloc_error_break to debug
MacOS system report provided this:
Crashed Thread: 0 JUCE Message Thread Dispatch queue: com.apple.main-thread
Attached the crash file.
Absolutely! I believe it stems from the UDP Bind Error issue. I think this happens if I have a pdlink~ object in an abstraction with multiple instances, and too many UDP devices are reaching for the same port. Either way, more than happy to use that build and attempt to help find the issue!!! On Jul 15, 2025 at 2:57 AM -0700, Timothy Schoen @.***>, wrote:
timothyschoen left a comment (plugdata-team/plugdata#2141) Hi! Can I send you a custom build to debug this issue further? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Hi @timothyschoen I have done further testing. I believe much of this has to do with pdlink~ and it having conflicts with other pdlink~ objects at start. If there is more than one pdlink~ object in the project, or in a multiplied abstraction, I will see a stack of UDP Bind Errors. This grows exponentially if abstracted.
This occurs even if the pdlink~ objects have different addresses. It appears they all attempt to grab the same UDP port at patch boot, then moving to another port. This can cause all types of downstream oddities if not dealt with. This occurs even if the DSP in a subpatch or abstraction is loadbang'd to 0.
For now, I am creating a system that dynamically loads an abstraction, when needed, for external audio recording. The system will also have a dynamically controlled clearing system for when external audio is no longer being accessed. This is a stand-in that will hopefully be unnecessary later.
If you eventually have a build to share that may attempt to address this, happy to give it a shot whenever. Not sure how folks coordinate that over GitHub, but I'm sure I can figure it out when the time comes.
It's unclear to me how a bug in [pdlink~] can lead to plugdata's standalone crashing at startup? Or are you starting up the patch using "open with", so it loads instantly?
I've seen the "UDP Bind Error" message myself too btw, I'll investigate that!
Sorry, I had been vague: plugdata crashes when I open a script, not usually when I open the program itself.
Hiya @timothyschoen Super excited about the update coming up! I see the udp bind error with pdlink~ continues to persist. Have you had a chance to dig in a little bit on that?
When you say "open a script", can you elaborate?
Are you starting plugdata from a script?
So, it is just when the patch opens at all. If I am opening it in standalone, for example, I will open the program, then select my patch from the recents, or file->open, or just launch plugdata by opening my patch from the finder. It also happens in plugin mode. If I do a test and 10 or 15 pdlink~ in a patch and attempt to launch the patch, it will often crash plugdata all together.
The issue isn't even instantiating them in the patch, its strictly when opening/booting the patch that this happens.
From what I can tell, when I open the patch, any pdlink~ object attempts to connect to a UDP port BEFORE the address takes effect. Either that, or they all attempt to connect to the same port, since they aren't scheduled one by one. And as a result, there becomes conflict. This conflict is somewhat resolved once the patch starts up in earnest, but, there is an odd behavior over time (at least on my MacBook Pro M1) where after about 10min to 20min, there are massive CPU spikes and an eventual crash. My guess is on some level, the pdlink~ objects are still trying to rectify their initial udp bind error in the background to the point of a crash.
Here are some images to show the sequence. But you can add them one by one, no issue. But after you save the patch, and then boot the patch, the UDP Bind Error occurs.
I checked the code for this, I think the UDP bind error message is harmless: this just means one of the attempts to bind failed, but it tries 32 times before quitting. Since we only see 3 of these messages, it means that it did bind successfully.
I believe the other crash you reported could still have to do with [pdlink~], but the UDP bind errors are unrelated. I should change the code so it only prints the error after failing 32 times though.
Okay, I will try some things now to see if the other symptoms of the problem persist. One test that used to cause a crash (having many pdlink~ objects in a patch and opening it) isn't causing the crash like it used to.
Next test, I will leave this patch open for a while, if we see an eventual cascade with the CPU usage, I will let you know. Often times, the way this takes shape is things work fine for a while. Over time, I will see a slight increase in CPU usage even without any other action. Finally, I will begin to see occasional 100% CPU spikes, which increase in frequency until there's a crash.
I will report back if that happens.
If not, we MAY be good. But I will hopefully be able to check with my main patch over the next few days.
Okay, I will try some things now to see if the other symptoms of the problem persist. One test that used to cause a crash (having many pdlink~ objects in a patch and opening it) isn't causing the crash like it used to.
Next test, I will leave this patch open for a while, if we see an eventual cascade with the CPU usage, I will let you know. Often times, the way this takes shape is things work fine for a while. Over time, I will see a slight increase in CPU usage even without any other action. Finally, I will begin to see occasional 100% CPU spikes, which increase in frequency until there's a crash.
I will report back if that happens.
If not, we MAY be good. But I will hopefully be able to check with my main patch over the next few days.
Thanks for looking into that more!
Okay, I kept PlugData on for more than half the day. It didn't have any issues. I won't have much time over the next few weeks to dig into my actual script, but there's a chance that work on the networking objects may have had knock on effects with pdlink~