__allocations_mutex can get deadlocked if an allocation happens in an allocation

[thegrb93]

This happened while using log4cxx. I worked-around the issue by just turning off log4cxx. It was on an old version of LeakTracer too so maybe it's been fixed since then. Maybe a recursive mutex or semaphore would fix the issue if not.

[thegrb93]

Looks like someone already had the same idea
https://github.com/fredericgermain/LeakTracer/blob/master/libleaktracer/include/Mutex.hpp#L44

I'll try uncommenting that and see if it works.

[thegrb93]

Worked. Might not for all cases, but for mine it stopped the deadlocking.

[fredericgermain]

Hi!
Thanks for reporting. Yes, this was quite a common problem when I started to use the lib. I tried to make it so to avoid that recursive mutex, as I don't like it by principle and would have rather it cleaner by having the init clearly ordered. But well, I can imagine some use cases are too difficult to deal with. I'm not sure I just write a small something about it in the README and make it easily activable with an environment variable, or I just make it the default. Or maybe there is another clever way.
It would depend on the performance of recursive vs simple mutex to make it the default. And I have no idea.

Could you just explain quickly what was your problem in your case? Or provide a little sample code?

[fredericgermain]

Also, I'm not sure recursive mutex would be available in all libc. glibc has it of course, but this tool targets all kind of embedded system.

[thegrb93]

Yeah it's probably situational. If I have time tomorrow I can make a short reproduction code. I'll have to look at the stack trace and see what log4cxx is doing.