ltalloc: infinite loop in ltsqueeze

Hi r-lyeh,

as promised, I have added some checks/validation in ltalloc.

The most important one being some optional buffer overrun detection using canary at the end of the allocated buffer. This feature can be enabled by defining the LTALLOC_OVERFLOW_DETECTION macro in your config.

The second one is less useful, but that’s the one that had helped me to detect the double free issue I had (first post). It won’t however detect all double frees, only consecutive ones, so it’s a bit limited for now (but it caught my issue, so still useful). This feature can be enabled by defining the LTALLOC_NEXT_POINTER_CHECK macro.

Now, I’ve tried to use your coding styles but you are welcome to check and change the code if required !

I haven’t clone the repository, so I am sending my changes as an updated ltalloc.cc file. Since that’s a single file I assume it will be easy for you to review my changes and merge what you want (had to zip for GitHub to accept my attachment).

Let me know if I can further help !

ltalloc.zip

Hi r-lyeh, I am again facing a weird issue, this time in release_thread_cache() call. Seems similar to my previous issue above (haven’t investigated yet), with the following loop being stuck: while (tail->next)//search for end of list

I’ll try to use the same methods and should be able to figure out the problem.

Still, this makes me think again that some kind of memguards checks and other optional validation layer could be very, very useful 😃

cheers, Greg

OK understood, this simply sets the pointer to null after freed. I was trying to figure out the role of the do…while() loop…

You were right, there was a double call to ltfree() (detected through the sanity-check code I’ve added :

void CheckBlockNext(FreeBlock *fb)
{
	if (fb && fb->next == fb)
	{
		imAssert(imFALSE);
		imCoreLib::ConsoleDisplay(imT("ltalloc problem detected"), imLOGGERMESSAGELEVEL_ERROR);
	}
}

void CheckBlockNext(ChunkSm *fb)
{
	if (fb && fb->next == fb)
	{
		imAssert(imFALSE);
		imCoreLib::ConsoleDisplay(imT("ltalloc problem detected"), imLOGGERMESSAGELEVEL_ERROR);
	}
}

I call those function just after any ->next is being set. Could be helpful for other people as well maybe (as long as it can be disabled completely through some preprocessor definition) - of course you’ll have to remove some custom types here (just for illustration).

Thanks a lot for putting me on the right track, very appreciated (as usual) 👍

No, I am affraid I can’t easily reproduce the issue, what’s quite annoying. It seems to be random, what’s not suprising since the software is pretty complex and multithreaded… I think I will first put some check when “->next” is being set, to detect when it’s set to the block pointer itself, maybe that would give me a clue…