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:m...@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:m...@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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list