[PD] debugging sporadic hangs at startup

Hans-Christoph Steiner 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":
http://www.tcl.tk/man/tcl8.5/TkCmd/console.htm

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
enable it.

.hc

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
>> pd-gui.tcl:
>>
>> exec -- $pd_exec -guiport $::port &
>>
>> to:
>>
>> exec -- $pd_exec -guiport $::port -d 1 >& /tmp/foo &
>>
>> (not sure if '>&" or '2>' depending on shell).
>>
>> cheers
>> Miller
>>
>> 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
>> terminal?
>>>> -----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
>>> at
>>>> least gets started up (which I assume it must have in order to start
>>> loading
>>>> the patch).
>>>>
>>>> cheers
>>>> Miller
>>>>
>>>> On Thu, Sep 27, 2012 at 12:22:57PM -0400, Ivica Ico Bukvic wrote:
>>>>> All,
>>>>>
>>>>>
>>>>>
>>>>> I am noticing sporadic GUI freezes when loading complex patches on
>>>> startup.
>>>>> 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
> file?
>>>>>
>>>>>
>>>>> 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 ->
>>>>> http://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list