__allocations_mutex can get deadlocked if an allocation happens in an allocation

Question

__allocations_mutex can get deadlocked if an allocation happens in an allocation

thegrb93 opened this issue 5 years ago · comments

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 · Answer 1 · Sat Jun 15 2019 05:27:02 GMT+0800 (China Standard Time)

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 · Answer 2 · Sat Jun 15 2019 13:44:27 GMT+0800 (China Standard Time)

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

fredericgermain · Answer 3 · Mon Jun 24 2019 03:59:04 GMT+0800 (China Standard Time)

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 · Answer 4 · Mon Jun 24 2019 04:00:54 GMT+0800 (China Standard Time)

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 · Answer 5 · Mon Jun 24 2019 07:56:48 GMT+0800 (China Standard Time)

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.