Script freezing: how can i debug?

[LovingAndRejected]

I seem to have this issue with a few of my scripts (particularly those collecting data). The present one freezes in initialization phase. In the test scenario it generates roghly 300 dataserver events, sequentially (ie. each new request is created in the dataserver response to the previous event). First roughly 100 llGetNotecardLine(), then 100 llRequestAgentData( ... , DATA_BORN ), then then 100 llRequestAgentData( ... , DATA_NAME ). The data are stored in strided lists.

it appears that after 250 events or so the script just freezes. No output on the debug console. What are my options to debug the situation and get a better understanding of the nature of teh problem?

if it's the data volume i could probably make the lists smaller by moving from key indices to integer indices, but I would really like to understand what is going on first.

[Dora Gustafson]

It is hard to tell exactly what goes on without seeing some scripts
My first guess is that you have an event buffer overflow
Size of event buffer is 64

The way to debug in LSL is to insert lines(llOwnerSay()) at strategic points in the code, that report data status

:smileysurprised::smileyvery-happy:

[LovingAndRejected]

---

Dora Gustafson wrote:

It is hard to tell exactly what goes on without seeing some scripts

My first guess is that you have an event buffer overflow

Size of event buffer is 64

The way to debug in LSL is to insert lines(llOwnerSay()) at strategic points in the code, that report data status

:smileysurprised:

:smileyvery-happy:

---

ok, thanks, i'm doing the llOwnerSay already. My event buffer should not have more than one event in the queue at any time...

[revochen Mayne]

If thers really no error message appearing then i guess its something within the llRequestAgentData calls.

Does your flow rely on a previous succeed  process? If yes, i would try to debug the agent keys and see if its always the same key used which makes the script freeze. Because the dataserver event doesnt trigger when you use an invalid avatar key. The dataserver event is missing something like a  "AGENT_KEY_INVALID" return flag.

 

llRequestAgentData("im an invalid key", DATA_BORN); compiles but  doesnt produce an error message nor triggers the dataserver event.

[LovingAndRejected]

---

revochen Mayne wrote:

. Because the dataserver event doesnt trigger when you use an invalid avatar key.

---

cool. I'll investigate in that direction. This is definitely important information, whether it is the casue of my problem or not. Thanks.

[PeterCanessa Oh]

Alongside this, it is good practice to implement a time-out on any dataserver() event so, if it doesn't fire (and stop the timer) you can capture the error in the timer() event.

[LepreKhaun]

---

LovingAndRejected wrote:

I seem to have this issue with a few of my scripts (particularly those collecting data). The present one freezes in initialization phase. In the test scenario it generates roghly 300 dataserver events, sequentially (ie. each new request is created in the dataserver response to the previous event). First roughly 100 llGetNotecardLine(), then 100 llRequestAgentData( ... , DATA_BORN ), then then 100 llRequestAgentData( ... , DATA_NAME ). The data are stored in strided lists.

 

it appears that after 250 events or so the script just freezes. No output on the debug console. What are my options to debug the situation and get a better understanding of the nature of teh problem?

 

if it's the data volume i could probably make the lists smaller by moving from key indices to integer indices, but I would really like to understand what is going on first.

---

Your problem is you have an extended loop with three actions it performs through each iteration and one of those actions at some point is hanging. To debug this, you need to first determine if this hang up occurs in the same place each time and (if so) then figure out which of the three actions is hanging and why.

 

So, to see if the hang up occurs in the same place each time, add the line llOwnerSay((string)lastKeyObtained); directly before each llGetNotecardLine(), with lastKeyObtained being set as named. If you find it hangs at a different place each time, you're failing to account for the possibility of lost data transmission.  To correct that, add a timer of (say) 10 seconds that gets bumped up every time a data request is made and, if triggered, resends the last data request.

 

If you find the hang up happens in the same place each time it then becomes simply figuring out what is causing it. It may be the line in the notecard itself, it may be in the key obtained from that line or it may be a coding error that is somehow stopping execution at that point.

 

To ascertain which, try removing the lines from the notecard before that point, removing the line itself and, finally, making a notecard containing just the line. Once you've isolated the problem line(s) (there may be more than one!), then you just need to identify what it is that causes the hang up.

 

Another approach to this would be to split the strided list into three and attempt to fill each one at a time. This would make it easier to pin point exactly where/what was causing the hang up. That is, if you can't fill the first list with the avatar keys, then you'd know there's a problem with the notecard itself. If you couldn't fill the second list (by looping through the first list), then there'd be a problem with one of the keys, which one could be easily determined with a LLOwnerSay((string)keyInQuestion); being called each time through the "extended loop". Transitioning between different states for each of these lists may make your debugging code easier to write and less error prone.

[LovingAndRejected]

Thanks for all the advice and suggestions. In the end I refactored the code to make the data structures smaller. It now runs successfully with the given data volume.

Regarding timeouts: that also is a valid point. However, it doen't quite explain the freezes I had experienced because the script should still react to touch events in the case of an outstanding dataserver event.

I have in fact implemented a reaction to a dataserver timeout in the timer event, but ultimately I will only print an abort message. The problem is that all events have so little context at runtime that they must operate on global data structures, which is intrinsically dangerous in an event-driven concurrent environment (luckily the events are serialized in LSL but it is difficult enough). Neither do the events have knowledge about other events waiting in the queue, or can manipulate them. I am not saying it is impossible, but any proper solution of this issue will not adhere to the KISS principle that should be the basis of any design.

As for the question in the title: it seems spraying llOwnerSay over the code is the only way of debugging, if the term "debugging" is even applicable in this case.

[PeterCanessa Oh]

---

LovingAndRejected wrote:

...

Regarding timeouts: that also is a valid point. However, it doen't quite explain the freezes I had experienced because the script should still react to touch events in the case of an outstanding dataserver event...

---

Very true - a dataserver request has no 'life' in the script until the responding event is raised so it shouldn't freeze the whole script and I didn't realise that was what was happening.  I thought it was simply that you weren't getting a response and so your script never got to issue the next request, so the whole thing became idle.

Not responding to other events is more of an issue and not an easy one!  Since you're only issuing one request at a time, as the preceeding response is received you shouldn't be filling the event queue, which is about the only thing I can think of.

[LovingAndRejected]

I spoke too soon, after some further changes the latest version started freezing too. I is not always deterministic, where the freeze occurs. it even happened inside llListSort() once.

However.

I did observe one thing I believe is the key: In addition to the currently processed item I kept an eye on llGetFreeMemory(). On one occasion I observed how the freeze coincided with free memory extrapolating to zero.

According to the Wiki this should resoult in a script error "stack heap collison" being reported, but that does not happen for me,

The quest continues...

[LepreKhaun]

---

PeterCanessa Oh wrote:

---

LovingAndRejected wrote:

...

Regarding timeouts: that also is a valid point. However, it doen't quite explain the freezes I had experienced because the script should still react to touch events in the case of an outstanding dataserver event...

---

Very true - a dataserver request has no 'life' in the script until the responding event is raised so it shouldn't freeze the whole script and I didn't realise that was what was happening.  I thought it was simply that you weren't getting a response and so your script never got to issue the next request, so the whole thing became idle.

Not responding to other events is more of an issue and not an easy one!  Since you're only issuing one request at a time, as the preceeding response is received you shouldn't be filling the event queue, which is about the only thing I can think of.

---

A minor clarification so there's no confusion: Over-filling the event queue results in dropped event messages. A hung script is the result of a triggered event handler never terminating, which may lead to filling the event queue.