stack heap collision

What steps can be taken to remove the stack heaap collision I am experiencing with the following code:-

list Adj;
integer Stride;
LoadAdj()
{
    Adj  = [2,3,4,0,0,0,0];
    Adj += [3,4,5,6,0,0,0];
    Adj += [4,3,6,7,0,0,0];
    Adj += [5,3,6,8,9,0,0];
    Adj += [6,3,4,5,7,9,10];
    Adj += [7,4,6,11,0,0,0];
    Adj += [8,5,9,16,17,0,0];
    Adj += [9,5,6,8,10,17,18];
    Adj += [10,6,7,9,11,18,19];
    Adj += [11,7,10,19,20,0,0];
    Adj += [12,13,25,0,0,0,0];
    Adj += [13,12,14,25,26,0,0];
    Adj += [14,13,15,26,27,0,0];
    Adj += [15,14,16,27,28,0,0];
    Adj += [16,8,15,17,28,29,0];
    Adj += [17,8,9,16,18,29,30];
    Adj += [18,9,10,17,19,30,31];
    Adj += [19,10,11,18,20,40,32];
    Adj += [20,11,19,21,32,33,0];
    Adj += [21,20,22,33,34,0,0];
    Adj += [22,21,23,34,35,0,0];
    Adj += [23,22,24,35,36,0,0];
    Adj += [24,23,36,0,0,0,0];
    Adj += [25,12,13,26,37,0,0];
    Adj += [26,13,14,25,27,37,38];
    Adj += [27,14,15,26,28,38,39];
    Adj += [28,15,16,27,29,39,40];
    Adj += [29,16,17,28,30,40,41];
    Adj += [30,17,18,29,31,41,42];
    Adj += [31,18,19,30,32,42,43];
    Adj += [32,19,20,31,33,43,44];
    Adj += [33,20,21,32,34,44,45];
    Adj += [34,21,22,33,35,45,46];
    Adj += [35,22,23,34,36,46,47];
    Adj += [36,23,24,35,47,0,0];
    Adj += [37,25,26,38,48,0,0];
    Adj += [38,26,27,37,39,48,49];
    Adj += [39,27,28,38,40,49,50];
    Adj += [40,28,29,39,41,50,51];
    Adj += [41,29,30,40,42,51,52];
    Adj += [42,30,31,41,43,52,53];
    Adj += [43,31,32,42,44,53,54];
    Adj += [44,32,33,43,45,54,55];
    Adj += [45,33,34,44,46,55,56];
    Adj += [46,34,35,45,47,56,57];
    Adj += [47,35,36,46,57,0,0];
    Adj += [48,37,38,49,58,0,0];
    Adj += [49,38,39,48,50,58,59];
    Adj += [50,39,40,49,51,59,60];
    Adj += [51,40,41,50,52,60,61];
    Adj += [52,41,42,51,53,61,62];
    Adj += [53,42,43,52,54,62,63];
    Adj += [54,43,44,53,55,63,64];
    Adj += [55,44,45,54,56,64,65];
    Adj += [56,45,46,55,57,65,66];
    Adj += [57,46,47,56,66,0,0];
    Adj += [58,48,49,59,67,68,0];
    Adj += [59,49,50,58,60,68,69];
    Adj += [60,50,51,59,61,69,70];
    Adj += [61,51,52,60,62,70,71];
    Adj += [62,52,53,61,63,71,72];
    Adj += [63,53,54,62,64,72,73];
    Adj += [64,54,55,63,65,73,74];
    Adj += [65,55,56,64,66,74,75];
    Adj += [66,56,57,65,75,76,0];
    Adj += [67,58,68,77,78,0,0];
    Adj += [68,58,59,67,69,78,79];
    Adj += [69,59,60,68,70,79,80];
    Adj += [70,60,61,69,71,80,81];
    Adj += [71,61,62,70,72,81,82];
    Adj += [72,62,63,71,73,82,83];
    Adj += [73,63,64,72,74,83,84];
    Adj += [74,64,65,73,75,84,85];
    Adj += [75,65,66,74,76,85,86];
    Adj += [76,66,75,86,87,0,0];
    Adj += [77,67,78,88,89,0,0];
    Adj += [78,67,68,77,79,89,90];
    Adj += [79,68,69,78,80,90,91];
    Adj += [80,69,70,79,81,91,92];
    Adj += [81,70,71,80,82,92,93];
    Adj += [82,71,72,81,83,93,94];
    Adj += [83,72,73,82,84,94,95];
    Adj += [84,73,74,83,85,95,96];
    Adj += [85,74,75,84,86,96,97];
    Adj += [86,75,76,85,87,97,98];
    Adj += [87,76,86,98,99,0,0];
    Adj += [88,77,89,100,101,0,0];
    Adj += [89,77,78,88,90,101,102];
    Adj += [90,78,79,89,91,102,103];
    Adj += [91,79,80,90,92,103,104];
    Adj += [92,80,81,91,93,104,105];
    Adj += [93,81,82,92,94,105,106];
    Adj += [94,82,83,0,0,0,0];
    Adj += [95,83,84,94,96,107,108];
    Adj += [96,84,85,95,97,108,109];
    Adj += [97,85,86,96,98,109,110];
    Adj += [98,86,87,97,99,110,111];
    Adj += [99,87,98,111,112,0,0];
    Adj += [100,88,101,0,0,0,0];
    Adj += [101,88,89,100,102,0,0];
    Adj += [102,89,90,101,103,0,0];
    Adj += [103,90,91,102,104,0,0];
    Adj += [104,91,92,103,105,113,0];
    Adj += [105,92,93,104,106,113,114];
    Adj += [106,93,94,105,107,114,115];
    Adj += [107,94,95,106,108,115,115];
    Adj += [108,95,96,107,109,116,0];
    Adj += [109,96,97,108,110,0,0];
    Adj += [110,97,98,109,111,0,0];
    Adj += [111,98,99,110,112,0,0];
    Adj += [112,99,111,0,0,0,0];
    Adj += [113,104,105,114,117,0,0];
    Adj += [114,105,105,113,115,117,118];
    Adj += [115,106,107,114,116,118,119];
    Adj += [116,107,108,115,119,0,0];
    Adj += [117,113,113,118,120,0,0];
    Adj += [118,114,115,117,119,120,121];
    Adj += [119,115,116,118,121,0,0];
    Adj += [120,117,118,121,122,0,0];
    Adj += [121,118,119,120,122,0,0];
    Adj += [122,120,121,0,0,0,0];
}

default
{
    state_entry()
    {
        LoadAdj();
        llOwnerSay(llList2String(Adj,7));
        list mylist = llList2ListStrided(Adj,1,90,7);
        string mystring = (string)mylist;
        llOwnerSay(mystring);
    }
}

This is a problem which is recurring in a number of linked prims. It might be possible to split the list over a number of prims to remove the 'stack heap' collision which occurs.

Is that the only way to remove it?

Over a number of scripts.

Good thread about memory issues : Stack-Heap Collision

You never say what you are trying to do or what the list represents.

If it's something you only need to access once or a few times, and the structure of the list is amenable to it, you could always store lines of data in a notecard, and then JUST fetch the line that you want. Or even use a strided list of lines in a notecard.

Obviously that would add a whole new layer of complexity with dataserver events, but then you wouldn't be trying to store a huge list in script memory during the entire run.

Also, I recall hearing that using += with lists requires TWICE the memory taken up by the list to execute. Lists are very inefficient, and what you are doing looks particularly so.

From the old LSL Wiki:




But, I'd guess you're still better off not trying to work with that huge list in memory.

Indeed it will have to be many many scripts.
The quoted Stack-heap Collision thread is a god send, thanks for it.



In actual fact it is for a new game, Chinese Chequers, or ChinChek. The board and its substructure consists of 148 prims. I have already had to split the scripts into the separate parts of the board base. I am now ready to do the coding of the 'moving' of the pieces. Done by changing the llSetAlpha to invisible or dimmed or flashing to accomodate the different states of the piece.

The list represents the adjacent points to a specific piece so that a move can be indicated to the player/s where their piece might 'move' to.

I have had lots of fun coding link_message, listen, timer and on_rez events and this is the last step. I will need two distinct 'lists' or perhaps strings to allow for the 'move' one position or the hopping over an adjacent piece with recursion to the limit of a move.

Still lots to do and I am having fun after many years (50) of coding learning a new language although it is not a very rich one.

This might be your best bet. The list you have, 847 integers, encoded as 3 digits each in a single string, would only take 2541b, vs. a list of 847 ints at 15b a pop, totalling 12705b, which is impossible to declare without overflowing the memory anyway.

Or, since none of the numbers exceed 255, encode them as 2 hex digits and save yourself 847b, with only the negligible overhead of prepending "0x" before casting back to an int.

That is certainly very helpful Deanna.
Anything to reduce the memory usage would help the performance of the string manipulation. Even so it will be unlikely to be possible to code the 'list' and the processing code in the same prim. I am therefore committed to communicating between two prims which is possibly a better solution anyway.
I am off to write the functions to return the requested values.
Thanks again