Good day -

After searching the forum cannot get any hits on this error... can you please enlighten me? TIA.

(PS: Something makes me think out of memory handles or xtree IDs? ... just started getting this after adding an editable column to an existing grid)

To be more specific... i can access the grid with the "SEX" editable field... the VERY NEXT xtree that displays craps out with the -9. So something getting set in the editable tree is lighting some sort of fuse...

After further review i have located the gremlin as the xtf2_autofilter switch. I removed it (wasn't necessary in this grid) and that eliminated the fatal error. Curious to be sure, but its a non issue for me. Tx.

-9 sounds like it could be related to a failure to load an image or bitmap. If the situation arises again, and/or you want to track it down, I suggest activating the XTREE and XDEBUG traces. That would probably get us close to the issue.

Then why would xtree be dying with -9? There are no images embedded in the xtree.

Here is the ashlog dump:

08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> SIGHUP trapped on: TSKAAD (edgemed500)
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> (Waiting for kbd wait or tcki to generate error; tinstate=1, rlock=0)
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> (Now in kbd wait; setting basic error #250)
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> XTREE warning: ATE response not formatted properly!
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> WARNING: PCKLST/XTREE fatal error code -9
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> (Now in xtree; setting basic error #250)
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> Trapped Basic Error #250 (Hangup signal (SIGHUP) received) at location counter 17A62
08-Feb-22 15:27:01 [p857-4]<CTS:0x17a62> Call stack trace, from program CTS : From loc 16caf, Gosub @16f57
08-Feb-22 15:27:01 [p857-4]<CTS:0x2c27> Job in kbd wait; cleaning up qflock & exiting.
08-Feb-22 15:27:01 [p857-4]<CTS:0x2c27> After qpurge & qclose

Ahhh!!! - That error -9 is a red herring arising from the "ATE response not formatted properly", which in turn arises from the SIGHUP. But I guess now you're going to say that the SIGHUP is being caused by the XCALL XTREE operation? In that case, it would seem to suggest that the client side is crashing. So we really need the traces on the client side, but if the session is really crashing, then you'll need to add them to the ATE copy of MIAME.INI so that they show up in the ATE copy of the ashlog.log file.

Ok, its a little cold for fishing, but perhaps you could give me a cause of the ATE response error? I am using the xtf2_anseqdata switch, i thought that was suppose to alleviate that problem?

The error code is extracted from the response package sent by the client back to the server on exit from an XTREE session. If the client disconnects uncleanly (such as when the user leaves the application sitting in an XTREE wait state and goes to lunch or home of the night and the network connection gets dropped), then the response packet is likely to be contain garbage, so the status code is not reliable in this instance. (The error #250 indicating SIGHUP is more important than the fatal error code -9, which may not indicate anything useful.)

I don't see any particular connection with the xtf2_anseqdata switch, which only tells XTREE that the answer array and data array have the same layout. That is a useful simplification (compared to the alternative), but I don't think it has any bearing on this situation. The real issue is whatever is causing the client to crash/disconnect. If the error is immediate and reproducible, then it presumably indicates a bug that should be fixed (although if you're running old versions, we should first make sure that it hasn't already been fixed). Capturing the traces on the client side might help that quest, but if not, the best fallback is if I can connect via ATE to the server to run the test/failing code. (If it somehow forces the client to crash, I could capture that.)

Ok thanks that explains the response not formatted properly message.

Running 1690 - not that far behind the pack. Thanks for the offer, it's been corrected on my end with tweaking the switches. You are free to get back to Jorge's requests...

Good day -

Still getting this -9 error code randomly. I have a suspicion it could be something to do with the xtree id getting confused (there are many xtrees over 3 folders that i am tracking). OR another resource issue... Is there a debug switch that could point me in some direction? And would it be client or server side? TIA

05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> SIGHUP trapped on: TSKAAD (edgemed500)
05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> (Waiting for kbd wait or tcki to generate error; tinstate=1, rlock=0)
05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> (Now in kbd wait; setting basic error #250)
05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> XTREE warning: ATE response not formatted properly!
05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> WARNING: PCKLST/XTREE fatal error code -9
05-May-22 11:14:08 [p32188-4]<CTS:0x16f51> (Now in xtree; setting basic error #250)
05-May-22 11:14:09 [p32188-4]<CTS:0x16f51> Trapped Basic Error #250 (Hangup signal (SIGHUP) received) at location counter 16F51
05-May-22 11:14:09 [p32188-4]<CTS:0x16f51> Call stack trace, from program CTS : From loc 1605f, Gosub @16375
05-May-22 11:14:09 [p32188-4]<CTS:0x2c27> Job in kbd wait; cleaning up qflock & exiting.
05-May-22 11:14:09 [p32188-4]<CTS:0x2c27> After qpurge & qclose

The error -9 here is a bit of a red herring. The real error is the SIGHUP, which is resulting in an incomplete response from the client to the server. The default SIGHUP handling is to just set a flag,roll the process into background (since it has lost its client connection) but otherwise don't disturb it until it needs input and then generate a Basic error #250. In this case that happens almost immediately (since the server side of XTREE has been essentially waiting on input from the client this whole time). But, Basic error handling typically occurs only between Basic instructions, so the XTREE routine waiting to receive the response from the client doesn't realize the SIGHUP occurred, which is why it reports its own XTREE error -9.

We probably should refine that logic so that XTREE can see the SIGHUP and thereby avoid adding to the confusion with it's own error code.

But in terms of getting to the bottom of the real problem, the question is why SIGHUP is occurring in the first place. Is it because the client simply went to lunch or home for the night without exiting from whatever XTREE session they were in, so that eventually an inactivity timer expires, terminating the connection? Or is the user just disconnecting from the File > Disconnect menu instead of backing out of the application in the normal way? (Note that you can password-protect the File > Disconnect.) Or is it some kind of network error unrelated to user or application activity? The SIGHUP traces in the log allow you to quantify the problem, but I'm not sure they can really do much to diagnose the cause. You probably have to start by looking for patterns (same users, same geographic/remote locations?) And then talking to the affected users to get their side of the story.

One trace that might help is EXEC (added under 6.5) which logs every RUN, CHAIN and LIT command. That might give you a sense of whether the SIGHUPs seem to occur randomly in the midst of normal activity for that user, or only after a long period with no other traces from the affected job. (The latter condition would seem more like some kind of network inactivity drop-out.)

Thanks for the reply.

Luckily (?) i was on the user PC when it occurred. The program was active but ATE was minimized for a few minutes, so it should have remained active. I cannot rule-out an underlying connection issue however. When we went back to the program and clicked on a row is when the error showed... so its very pausible the connection was already lost. I was more concerned that perhaps i was causing the error by mis-managing the xtrees in the first place (like, re-entering a grid with an ID that was no-longer actively on the screen).

I will continue to try to triage conditions.

Thanks.

Right - and just to clarify, the symptom of it appearing to be alive but the error shows up when you click on a row is consistent with the network connection having been dropped without either end initiating it. The client would detect the problem only when it tried to send the result back to the server (in response to the click).