I have a humongous patch that I won't share (it's too big and complicated and messy and undocumented to mean anything). Last night I was running it for an hour or so (two versions, actually, but all my variables are with $0- so they can go simultaneously) and it eventually reached a point where it would just stop all computation for up to twenty(?) seconds. All audio, all GUI, everything froze. Not my computer, though, definitely just PD. "Audio Error" (or whatever shows up next to the DSP on the main window) would turn red when this would happen.

I'm running Linux, and I was not getting any XRuns (which is another hint that it's just PD that's bogging down, not my whole system).

I know this isn't a lot to go on, but have people seen this before? I have some theories: I have large tables being written to, but even if I close them (to ease up on the GUI), it continues to happen. Another thought - I have lots of counters... a long time ago, I tried to put in some checks where, if they got over a certain range, I'd set them back to zero. If I missed some, could that cause PD to freeze? If I was using a simple counter and it got into the millions/billions? Hmm, a billion milliseconds is almost twelve days...

@Load074 You could add a [print name] to your tables and counters.... which could give some clues and might actually decrease the "time to freeze" and make it easier to debug.
Does it also happen if you minimize all the windows except the console?
David.

Thanks David - I'll start trying this troubleshooting/tracing method. When this happened last, I believe it was freezing regardless of which windows were open. I should try again with everything minimized... but it's tricky, cuz it takes a long time (an hour?) for the freezing to commence.

@Load074 Since it takes so long you may want to just log all those prints externally. You can use the pdreceive command line application to send the data out of pd with the [netsend] object. So instead of connecting thing to various [print] objects you prepend a descriptive label to the data and then send that into [netsend]. Run pdreceive [port number] >> [logfile name] then send the [connect <port number>( to your [netsend] object in pd, and start the patch, everything gets send there. Then you can use a text editor or the standard command line tools to examine the text file after the crash, just control-c to kill pdreceive after pd freezes. Useful tools too examine the log will be things like tail and grep, tail -50 [logfile] will give you the last 50 lines of the log, tail -50 [logfile] | grep [label] will give you the last 50 occurances of all entries for [label]. Should make it much easier to decode the problem. The [trace] object could also be of use here. And there are a great number of other useful tools on the command line, any of the tools used for working with text files like cut and sort and the shells own scripting language, any good guide for your shell should help you here if you do not have much experience with shell scripting and the command line apps.

And time is relative, no need to wait an hour, speed up your control objects, if everything is under control of a master [metro] make it run 10 times faster and you will get your result in a tenth of the time. If you are logging it all to a file you do not need things to run slow enough that you can read them in the log window.

while i understand that you dont want to isolate the problem by creating a new partial patch for the forums, this is the only way how to solve it after all.

data rate initialisation or network activity are good guesses, but if you dont even have it under control where in your patch such things happen...