Heap help

[LTee]

Hi boriel,

I wondered if you could help me understand the heap a little better? Reading the forum I've determined that the heap is mainly used for string handling and by default is just over 4k in length (but may take up the rest of memory - is that right?)

My program is fairly large (just over 30K when compiled with -O2, I am compiling from address 24576 to give me extra space). When running it does quite a lot of string manipulation and I've noticed that it becomes steadily more unstable over time until it finally crashes, either with an 'out of memory' (I'm using --debug-memory) or screen corruption appears and the Spectrum crashes. I'm thinking that either I don't have enough heap or something is quietly writing over areas of memory that it shouldn't and after a while that brings the whole thing crashing down. I've tried increasing (and decreasing!) the heap space with the -H command, but it doesn't seem to make any difference.

How can I tell where the heap is located in memory, and how big it is? Is there any way to get the running program to output how much heap space it thinks is left? The heap should always be located after the compiled code in memory, right? And all string data should be in the heap? I tried compiling with the -d option but this generates tons of output, most of which I don't really understand.

Does anyone have any advice on things to look for that might be causing problems like this? The program I'm working with was originally a Sinclair BASIC listing so it relies quite heavily on GO SUB/RETURN, too, so I guess it's possible that it might be nothing to do with the heap and maybe something stack-related? Grasping at straws really, I'm really just looking for a bit of advice on what I could investigate next.

Thanks!

[boriel]

Heap is uses for string handling yes.
You can manage it using the library alloc.bas (use #include)
There you have memavail (total free memory) and maxavail (maximum chunk available). This memory is fragmented over time (list of free blocks).
So if you have 256bytes and 64 bytes (2 blocks) of free memory, memavail will return 256 + 64 = 320 bytes, and maxavail will return 256.

You can reduce the heap with the --heap compiler flag. Also use --asm and list the asm. There is a HEAP label.
Generating the binary afterwards with: zxbasm --mmap=program.map yourprog.asm you will get a memory map to detect where is the heap (usually at after your program).
Using a lower org (default 32768, but try 25000), your stack will be reduced, but you will get 5000 bytes extra for heap. The heap (I dont recall at this moment) takes the available space between your code and the UDG zone.

[LTee]

Fantastic - that's exactly what I was looking for. Thanks, boriel - I'll investigate further tonight and see if I can figure out what's going on.

[LTee]

Wow, something's really wrecking my heap. I set it to 8000 bytes and at startup it shows 7787 bytes free for both memavail and maxavail.

However, after my first chunk of game setup code runs something REALLY weird happens - both values can show completely crazy numbers. The screen I'm looking at right now is showing 37612 for memavail and 52373 for maxavail, but it doesn't seem to happen every time and the numbers are nearly always different every run (possibly due to my relying heavily on random numbers during the game setup).

I'm going to try to narrow down exactly where this is happening by knocking out pieces of code and seeing what effect they have, but do you have any ideas what kind of thing could cause something like this?

[LTee]

Okay, don't worry about that last question - that turned out to be easier to narrow down than I thought. It looks like a fairly innocent-looking loop of string handling is causing everything that's going wrong with my program - take that part out and everything seems to behave perfectly.

I'm going to try to extract just that section out into a test program. If the same thing happens outside of my main game code then I'm guessing it's a bug and I'll log it in the other part of the forum.

Thanks again for the advice, it's really helped me get going again!

[boriel]

A Debugging tool is something we (the community) is starting to figure out. Please, patience :roll: (but stay tuned)