How detect and fix heap trashing ?

@kas1e
You should probably put the full source and your analyzer logs somewhere so we can take a better look. E.g. we don't even know how the structs look like etc.

@Daniel

Source:
https://sourceforge.net/p/foobillardplus/code/HEAD/tree/src/

DrMemory logs file "results.txt" (120kb) :
http://kas1e.mikendezign.com/aos4/gl4 ... llardplusplus/results.txt

DrMemory logs file "potential errors" (660kb):
http://kas1e.mikendezign.com/aos4/gl4 ... plus/potential_errors.txt


Result.txt one is which is bugs for sure, search there for "menu.c" , "font.c" and "textojb.c" for those 3 bugs it found.
"Potentional errors" as usuall can be all kind of false alarms of course

@kas1e

getStringPixmapFT()/my_draw_bitmap() likely trashes mem when blitting into chunky buffer (data) -> font glyph info/"coords" (bitmap_left) maybe can have values the code does not expect (like negative ones). Because of kerning or whatever. my_draw_bitmap() isn't clipping anything.

Try

@kas1e
Ouch, I see, this is the code where you got that completely messed up sound-file-extension code from...

@Georg
yes, worth a try. Commenting out that draw-code seemed to help.

@Daniel
Yeah, is that one :) We don't have normal billiard games (there some other old one, pure "billard" on os4depot, but it suck heavy, no sound, no music, dated look, etc). This one (foobillard++), is looks good, plays good, and i almost have no needs to worry about endianes (just in one place, where they load raw sound via fread()).

So, want to deal with all this, as game at least works already over gl4es/ogles/warp3d.

@Daniel,Georg

Yeah, we very close ! With that function, when i come to those entries which crashes before, it didn't now, but that what it bring to console:



That for 4 different places where it crashes before.

And visually, it also start to miss first letters. In some places. See screesnhots:

http://kas1e.mikendezign.com/aos4/gl4 ... obillardplusplus_fix1.jpg
http://kas1e.mikendezign.com/aos4/gl4 ... obillardplusplus_fix2.jpg
http://kas1e.mikendezign.com/aos4/gl4 ... obillardplusplus_fix3.jpg

On first you can see at top of game (no the menu entries itself, but at left top side , pure help-message), there is words "hank you very much" , while should be "Thank you very much". On second one "ypes", but should be "Types". And on third screenshot, this time it miss from menu entry in the world "Yes" first "Y.

When its all buggy , and i just comment out free(textdata) to avoid crashes, all letters are in place (but that of course trash the memory).

@kas1e

Quick fix (assumes only blitx can be out of bounds (on left side)). Undo previous stuff (kprintf), first:

@Georg
Yeah, it did the trick !

Through as i understand we just avoid accessing to trashed memory, while some parts of memory still trashed and leaks still there ?

@Georg
Dunno if it another bug, or related to that trashed memory, but
another bug arise in another place : not with free(), but with just accessing to some data via that line:



Its from the same menu.c , just in the menu_choose() this time. Crashes exactly on that first line "if( (*menu)->parent_entry != 0 ){" :

https://sourceforge.net/p/foobillardpl ... HEAD/tree/src/menu.c#l406

Visually, it happens when i just choice one of the menu entries (few of them cause that crash). Dunno if it related through, or if it just another different issue with that shit-code ..

Probabaly as accessing is to "*menu" , maybe its again abou trashed heap ?

@kas1e

Crash is more likely second line ("if( (*menu)->parent_entry->show_subsetting )") with parent_entry likely being uninitialized.

Add a line to menu_new() which sets menu->parent_entry to 0. Or change the malloc in there to calloc.

@kas1e

Quote:

It avoids blitting outside left bounds (and thus trashing memory there) because that's what debug output shows it did (negative coords). So the change causes the bitmap to be allocated bigger (wider) and the blits to be offset to the right so that final blit X position of each glyph (char in string) is always >= 0.

Theoretically (weird fonts/languages/accents?) it could still blit outside right/bottom/top side. So to be 100 % safe you would need to check all sides. ~

@Georg
Yeah, you was right ! Just setting "menu->parent_entry = 0;" in menu_new did the trick ! Thanks a bunch!

Will also add better check on possible negative values as you show.

Thanks again, hope there will be no new bugs of this kind :)

.