[PD] debugging sporadic hangs at startup
hans at at.or.at
Fri Sep 28 16:14:14 CEST 2012
This might be a good opportunity to rewrite some parts of the s_inter.c
mess. I did this kind of debugging on Mac OS X simply because the way
s_inter.c handles the Tcl process means that you can run the Tcl
console, which is incredibly valuable for debugging the GUI.
For an example of that on GNU/Linux, run 'wish'. You'll see that it
launches a barebones wish window, but you'll also see that wish gives
you a prompt. That's a live prompt where you can edit the currently
running program, as well as get stdout and stderr. The GNU/Linux code
in s_inter.c suppresses that console entirely so that the 'pd' process
doesn't give the same console.
The Mac OS X Wish.app handles this nicely making this issue easy: it
provides a default menu bar with an option to launch the console in its
own window, or that is launchable with the command "console show":
It would be nice to be able to do this on other platforms besides Mac OS
X. That will require changes in how s_inter.c starts the wish process,
I think. Perhaps there could be a -tclconsole command line flag to
On 09/28/2012 09:27 AM, Ivica Ico Bukvic wrote:
> So, this does not catch any of the tcl errors (or perhaps none were
> generated). Short of rewriting how messages are broadcast, is there an easy
> and global way of redirecting all tcl output errors to a file? I read about
> interp bgerror, but am not sure if this will catch networked stuff (which is
> the likely offender here) or even work at all...
> Similarly, I am wondering if a part of the problem is the 20000 size limit
> on the networked data buffer (CHUNKSIZE in t_tkcmd.c) in that during the
> startup because atom cpu is getting swamped perhaps it does not have enough
> time to catch-up with queued networked messages being spewed out of C code
> over the socket and then drops some stuff and hence the non-functioning gui?
> If so, another possible offender would be INBUFSIZE in s_inter.c that deals
> with messages coming from the pd-gui...
> Any thoughts?
>> -----Original Message-----
>> From: Miller Puckette [mailto:msp at ucsd.edu]
>> Sent: Thursday, September 27, 2012 1:34 PM
>> To: Ivica Ico Bukvic
>> Cc: pd-list at iem.at
>> Subject: Re: [PD] debugging sporadic hangs at startup
>> I've never done this but perhaps it would work to edit the line in
>> exec -- $pd_exec -guiport $::port &
>> exec -- $pd_exec -guiport $::port -d 1 >& /tmp/foo &
>> (not sure if '>&" or '2>' depending on shell).
>> On Thu, Sep 27, 2012 at 01:23:23PM -0400, Ivica Ico Bukvic wrote:
>>> This is actually on Linux.
>>> The problem is likely not in C, since program does start up and
>>> creates the main Pd window and then hangs during loading of the patch
>>> (the patch window is created but canvas remains empty and after that
>>> nothing responds any more). It seems to me this is probably because at
>>> some point messages sent to tcl/tk over network (from C) get mangled
>>> after which gui stops responding. I had issues like these before with
>>> network externals and solved them, but this is the one that I had a
>>> hard time weeding out since it is so sporadic. For this reason, I
>>> would like to somehow output all tcl/tk commands that were sent to
>>> gui. Any way to do this and send it to a separate log file without
> opening a
>>>> -----Original Message-----
>>>> From: Miller Puckette [mailto:msp at ucsd.edu]
>>>> Sent: Thursday, September 27, 2012 12:27 PM
>>>> To: Ivica Ico Bukvic
>>>> Cc: pd-list at iem.at
>>>> Subject: Re: [PD] debugging sporadic hangs at startup
>>>> On Macintosh I presume...
>>>> Maybe you can use gdb to 'attach' to the running Pd process,
>>>> assuming it
>>>> least gets started up (which I assume it must have in order to start
>>>> the patch).
>>>> On Thu, Sep 27, 2012 at 12:22:57PM -0400, Ivica Ico Bukvic wrote:
>>>>> I am noticing sporadic GUI freezes when loading complex patches on
>>>>> How would one go about debugging this when most of such startups
>>>>> happen by clicking on the app icon (so no access to gdb or console).
>>>>> Short of changing the app icon to make everyone's apps always
>>>>> start with gdb, is there a way to redirect debugging output to a
>>>>> On a related matter, any other users noticed these ocassional
>>>>> hangs when loading a complex patch (the window opens but remains
>>>>> blank and clicking on any options in the menu does nothing)?
>>>>> Pd-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list