clock format causes infinite loop? with its use of "dict exists"
in [TCL]
|
From: Ian Mac on 5 Aug 2010 07:45 Hello all What steps will reproduce the problem? That is a hard one, I have a procedure which I call to log the progress of a batch control job. This job has been running for many days and has called the procedure many many times (<500,000) This event has occurred 3 times during that time, it is hard to tell if it is linked to real time. The errors have occurred from 3 different start points. The procedure I have is quite simple proc log { msg } { $::LOG_WIDGET insert end "\[[clock format [clock seconds] -format "%H:%M:%S"]\] $msg\n" $::LOG_WIDGET see end } This is the error message which appears on the console screen. too many nested evaluations (infinite loop?) while executing "dict exists $TimeZoneBad $timezone" (procedure "GetSystemTimeZone" line 21) invoked from within "GetSystemTimeZone" (procedure "::tcl::clock::format" line 13) invoked from within "clock format [clock seconds] -format "%H:%M:%S"" (procedure "log" line 2) invoked from within "log "> about to evaluate the jobline \"$buffer\""" (procedure "readChannel" line 24) invoked from within "readChannel sock312" As you can see the log command was on this occasion invoked from my call of my procedure readChannel, on another occasions it was other of my procedures which called the log procedure. I would suggest there is some special case where the internal dict is nested or the like due to concurrent activity, with say an after or vwait command, although I have no proof of this, so it may be a red herring! I am not sure how to diagnose this internal tcl command failure further. I have looked at the body of ::tcl::clock::GetSystemTimeZone but do not understand how to proceed further. tcl_patchLevel 8.5.4 -- cheers Ian Mac
From: Andreas Leitgeb on 5 Aug 2010 09:04 Ian Mac <ianmac.uk(a)gmail.com> wrote: > too many nested evaluations (infinite loop?) > while executing > "dict exists $TimeZoneBad $timezone" > (procedure "GetSystemTimeZone" line 21) > invoked from within A possible reason: Your own app has an endless recursion, and one of the involved procedures does the catch (therefore the backtrace isn't so much longer). To diagnose that, also dump [info level] where you dumped the errorInfo. furthermore: create a chain of, say, ten procs, that call each the next: proc p10 {} p9; proc p9 {} p8; proc p8 {} p7; ... ;proc p0 {} {} and call p10 from inside your procedure "log" just before [clock...]. If your app hits the recursion limit itself, then the error will now occur in the chain of p#'s, no longer in [clock ...]. A wild guess on a possible reason for such a non-deterministic recursion: Are you, by a chance, calling "update"(or even vwait or tkwait) from readChannel, and having your readChannel called by fileevent? If so, then sufficiently fast input could result in a stackup of these readChannel-calls.
From: Gerald W. Lester on 5 Aug 2010 10:35 Andreas Leitgeb wrote: > Ian Mac <ianmac.uk(a)gmail.com> wrote: >> too many nested evaluations (infinite loop?) >> while executing >> "dict exists $TimeZoneBad $timezone" >> (procedure "GetSystemTimeZone" line 21) >> invoked from within > > A possible reason: > Your own app has an endless recursion, and one of the involved > procedures does the catch (therefore the backtrace isn't so much > longer). To diagnose that, also dump [info level] where you > dumped the errorInfo. > > furthermore: create a chain of, say, ten procs, that call each the next: > proc p10 {} p9; proc p9 {} p8; proc p8 {} p7; ... ;proc p0 {} {} > and call p10 from inside your procedure "log" just before [clock...]. > If your app hits the recursion limit itself, then the error will now > occur in the chain of p#'s, no longer in [clock ...]. > > A wild guess on a possible reason for such a non-deterministic recursion: > Are you, by a chance, calling "update"(or even vwait or tkwait) from > readChannel, and having your readChannel called by fileevent? > If so, then sufficiently fast input could result in a stackup of these > readChannel-calls. > The same symptoms could result if he keeps entering the event loop explicitly (tk_wait or update). -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester(a)kng-consulting.net | +------------------------------------------------------------------------+
From: tom.rmadilo on 5 Aug 2010 12:09 On Aug 5, 4:45 am, Ian Mac <ianmac...(a)gmail.com> wrote: > Hello all > > What steps will reproduce the problem? > > That is a hard one, I have a procedure which I call to log the > progress of a batch control job. This job has been running for many > days and has called the procedure many many times (<500,000) This > event has occurred 3 times during that time, it is hard to tell if it > is linked to real time. The errors have occurred from 3 different > start points. > > The procedure I have is quite simple > > proc log { msg } { > $::LOG_WIDGET insert end "\[[clock format [clock seconds] -format > "%H:%M:%S"]\] $msg\n" > $::LOG_WIDGET see end > > } > > This is the error message which appears on the console screen. > > too many nested evaluations (infinite loop?) > while executing > "dict exists $TimeZoneBad $timezone" > (procedure "GetSystemTimeZone" line 21) > invoked from within > "GetSystemTimeZone" > (procedure "::tcl::clock::format" line 13) > invoked from within > "clock format [clock seconds] -format "%H:%M:%S"" > (procedure "log" line 2) > invoked from within > "log "> about to evaluate the jobline \"$buffer\""" > (procedure "readChannel" line 24) > invoked from within > "readChannel sock312" > > As you can see the log command was on this occasion invoked from my > call of my procedure readChannel, on another occasions it was other of > my procedures which called the log procedure. > > I would suggest there is some special case where the internal dict is > nested or the like due to concurrent activity, with say an after or > vwait command, although I have no proof of this, so it may be a red > herring! > > I am not sure how to diagnose this internal tcl command failure > further. > I have looked at the body of ::tcl::clock::GetSystemTimeZone > but do not understand how to proceed further. > > tcl_patchLevel 8.5.4 If $::LOG_WIDGET == "log", your proc is an infinite loop, calling itself. But you could also just have exceeded the max stack depth. However, you haven't posted enough code to say, why not post the entire error message?
From: Ian Mac on 5 Aug 2010 12:48 On Aug 5, 5:09 pm, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > On Aug 5, 4:45 am, Ian Mac <ianmac...(a)gmail.com> wrote: > > > > > Hello all > > > What steps will reproduce the problem? > > > That is a hard one, I have a procedure which I call to log the > > progress of a batch control job. This job has been running for many > > days and has called the procedure many many times (<500,000) This > > event has occurred 3 times during that time, it is hard to tell if it > > is linked to real time. The errors have occurred from 3 different > > start points. > > > The procedure I have is quite simple > > > proc log { msg } { > > $::LOG_WIDGET insert end "\[[clock format [clock seconds] -format > > "%H:%M:%S"]\] $msg\n" > > $::LOG_WIDGET see end > > > } > > > This is the error message which appears on the console screen. > > > too many nested evaluations (infinite loop?) > > while executing > > "dict exists $TimeZoneBad $timezone" > > (procedure "GetSystemTimeZone" line 21) > > invoked from within > > "GetSystemTimeZone" > > (procedure "::tcl::clock::format" line 13) > > invoked from within > > "clock format [clock seconds] -format "%H:%M:%S"" > > (procedure "log" line 2) > > invoked from within > > "log "> about to evaluate the jobline \"$buffer\""" > > (procedure "readChannel" line 24) > > invoked from within > > "readChannel sock312" > > > As you can see the log command was on this occasion invoked from my > > call of my procedure readChannel, on another occasions it was other of > > my procedures which called the log procedure. > > > I would suggest there is some special case where the internal dict is > > nested or the like due to concurrent activity, with say an after or > > vwait command, although I have no proof of this, so it may be a red > > herring! > > > I am not sure how to diagnose this internal tcl command failure > > further. > > I have looked at the body of ::tcl::clock::GetSystemTimeZone > > but do not understand how to proceed further. > > > tcl_patchLevel 8.5.4 > > If $::LOG_WIDGET == "log", your proc is an infinite loop, calling > itself. But you could also just have exceeded the max stack depth. > > However, you haven't posted enough code to say, why not post the > entire error message? I have posted the entire error message, as currently reported. This is the code which generates the log frame pack [TitleFrame .fMain.fMasters -text "Masters"] -fill both -expand no pack [TitleFrame .fMain.fStatus -text "Status"] -fill both -expand no pack [TitleFrame .fMain.fLog -text "Log"] -fill both -expand yes # -- Masters frame--------------------------- set f [.fMain.fMasters getframe] set MASTER_FRAME $f # -- Log frame ------------------------------- set f [.fMain.fLog getframe] pack [scrollbar $f.sbVert -command "$f.tLog yview"] -side right -fill y pack [text $f.tLog -height 8 -yscrollcommand "$f.sbVert set"] -fill both -expand yes -side left set LOG_WIDGET $f.tLog The procedure log is called all over the place in response to an incoming message from a remote task, so effectively it is invoked somewhere in the fileevent tree. However I should point out that this all worked with tcl 8.3 and I never saw the message. I believe it is something to do with the implementation of dict There does appear to be talk of such a bug associated with dict but I do not understand how to gather more evidence of the failure, especially as I can't create it at will.
|
Next
|
Last
Pages: 1 2 3 Prev: how to identify odd 1's in a binary number using regexp Next: regexp help |