state(after) no such element in array error

[rosc2112]

OK I just saw a post in the junk yard, with an error msg about state(after) and I had someone send me an email recently saying that the weather script I had was also failing with that error. However, the weather script does not have any $state variables, anymore (I renamed the one $state var thinking it might be conflicting with some other script). The post in the junk yard was about the tvrage.com script ...

My question is, what the heck is this state(after) var..?

Hmm.. I just checked the tcl-http package manpage and it does have a state() var, but, I don't see anything about state(after) Apparently there's some weirdness with the tcl-http package on some platforms, but I'm at a loss to track it down, not having access to the systems showing the error. Maybe someone else has some insight into what the problem is.

[Alchera]

<Alchera> .set errorInfo
<StarFighter> [21:50] #Alchera# set errorInfo
<StarFighter> Currently: can't read "state(after)": no such element in array
<StarFighter> Currently: while executing
<StarFighter> Currently: "after cancel $state(after)"

I decided to do a .set errorInfo (as one does when one is bored) and got the above in about 5 bots (picked randomly).

I am in gentoo atm and have "grepped" just about every eggdrop source file result (so far).

So far I have snprintf.c and coredns.c referencing 'state':

Code: Select all

snprintf.c:/* format read states */
snprintf.c:  int state;
snprintf.c:  state = DP_S_DEFAULT;
snprintf.c:  while (state != DP_S_DONE) {
snprintf.c:      state = DP_S_DONE;
snprintf.c:    switch (state) {
snprintf.c:        state = DP_S_FLAGS;
snprintf.c:        state = DP_S_MIN;
snprintf.c:        state = DP_S_DOT;
snprintf.c:        state = DP_S_DOT;
snprintf.c:        state = DP_S_MAX;
snprintf.c:        state = DP_S_MOD;
snprintf.c:        state = DP_S_MOD;
snprintf.c:        state = DP_S_MOD;
snprintf.c:      state = DP_S_CONV;
snprintf.c:      state = DP_S_DEFAULT;

Code: Select all

coredns.c:  switch (getheader_rcode(hp)) {
coredns.c:      switch (rp->state) {      /* Construct expected query reply */
coredns.c:      switch (qdatatype) {
coredns.c:            switch (datatype) {
coredns.c:    switch (rp->state) {
coredns.c:    switch (rp->state) {

and I know not one Tcl script I have uses any variable as stated above.

Any clues?

NB: I only see this "error" (bug?) in the 1.6.18 bots; not version 1.6.17.

[nml375]

@rosc:
You'll find this piece of code in the http-package, within the procedure httpFinish:

Code: Select all

catch {after cancel $state(after)}

However, since it's caught, it should'nt affect the script

The purpose of the state(after) variable is to keep track of an time delayed command (much similar to eggdrop's timers), handling timed out requests..

If a request would time out and you'd still call httpFinish, there'd be no delayed command to cancel, hence an error condition would arise.. which is why it's "caught"

Although I hav'nt read the initial thread; my guess would be there's another error that occurs, but since we're dealing with delayed commands, the errorInfo variable is rewritten by the http-package as a http-request times out..

[rosc2112]

If a request would time out and you'd still call httpFinish, there'd be no delayed command to cancel, hence an error condition would arise.. which is why it's "caught"

Hmm..Yeah I do in fact call http::cleanup in my scripts if the geturl produces an error or a timeout.

For example:

Code: Select all

                if { [::http::status $page] == "timeout" } {
                        ::http::cleanup $page
                        return "Error - Connection timed out. (1)"
                }

I don't think that this state(after) error would be causing a problem tho, but I don't have enough info from the person who reported it to me yet.
I have not seen this state(after) error myself, I've been trying to debug it for someone else that has reported the error to me in regard to the weather script I made/modified. Someone else mentioned it here on the forums too, in regard to the tvrage script (but that post is in the junkyard.)

Just curious where it was coming from, so thank you for helping find it in the src, it might be helpful in finding the problem this one person is experiencing with the weather script (and maybe also for the person having a problem with the tvrage script.)

I have to wait for the person having problems with the weather script to report back to me about the results of a debug copy I sent him, maybe that'll provide more clues.

I'll reply here if I find any more info or a solution.

[rosc2112]

I should also mention the reason I call http::cleanup after an error, is cos the documentation was not clear about whether the http socket would be closed or not, so I figured it wouldn't hurt to close it before returning from the error.

[Dedan]

try:

Code: Select all

   if {[catch {after cancel $state(after)}]} {}

[nml375]

I'm not sure what that'd accomplish..
In any case, I'm quite sure the error is not within the http-package. The only reason that turns up in ".set errorInfo" is because it's most likely run after the error has occured, and thus overwriting the real error message with the one that's already caught...

Also, I really don't see the point of adding that conditional construct. Care to enlighten me of it's purpose?

[rosc2112]

If I could figure out a way to set up a test scenario, I could see what the previous error might have been that the state(after) thing is clobbering.

Obviously I could put in 'putcmdlog' strings to see what the content of $error is, I just don't know how to actually produce the errors. The only errors I'm aware of are the timeout and 'couldn't open socket' errors, which my scripts already handle.

I wonder if putting in a test for

if {$error != ""} {putcmdlog "scriptname '$error'"}

would give any insight. Although the $error var sometimes also includes stuff even when the command was successful.

I've not seen the state(after) error myself, so I have no way to replicate it, and the person who told me they were getting that error from my weather script still has not replied about the results of debug copy I sent them. Maybe they gave up.