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@ucsd.edu] Sent: Thursday, September 27, 2012 1:34 PM To: Ivica Ico Bukvic Cc: pd-list@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@ucsd.edu] Sent: Thursday, September 27, 2012 12:27 PM To: Ivica Ico Bukvic Cc: pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list