hang at end in loadCurrentStack

[aulwes]

Hi, I've built the latest repo but in gdb, it looks like Malt is hanging in loadCurrentStack. looking at backtrace in gdb, I see

#0 0x00001554da17c4cd in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00001554da175ac9 in pthread_mutex_lock () from /lib64/libpthread.so.0

so it looks like it's hanging on a pthread lock. is it possible to build without using pthread?

[aulwes]

I tried setting -DPORTABILITY_MUTEX=DUMMY -DPORTABILITY_SPINLOCK=DUMMY, but when I tried to compile, I get compile error

src/libinstrum/./portability/Mutex.hpp:36:11: fatal error: 'MutexDummy.hpp' file not found
36 | #include "MutexDummy.hpp"

[svalat]

Hi, thanks for reporting,
I first looked about your second message, true, I have a missing file. I made a fix so now it will build.

I will give a look in the hang.

Any chance to have a small reproducer on the conditions ?

[svalat]

In case the fix for the MutexDummy issue is in branch develop until next release.

[aulwes]

Let me see if I can create a reproducer. Thanks, I'll grab your fix from develop branch.

[aulwes]

I see LockDummy.hpp in develop branch but not MutexDummy.hpp

[svalat]

Oopos sorry, I forgot to push to the public repo. Done.

[aulwes]

Thank you!

[aulwes]

Just updated develop branch, but getting this compile error:

src/libinstrum/./portability/Spinlock.hpp:37:11: error: unknown type name 'SpinlockDummy'
37 | typedef SpinlockDummy Spinlock;
| ^

[aulwes]

So if I replace SpinlockDummy with LockDummy, then I can compile. Now, when I try to run, I'm getting an abort because of

MALT_ASSERT(this->prev->next == this);

in FreeChunk::removeFromList() in SimpleAllocator.cpp. This was called from SimpleAllocator::getInList(). Any ideas why this assertion is failing?

[svalat]

Hum, sorry, was not fresh enough when making the patch, I forgot is was shared and enabled Dummy only on Mutex for my test.

I fixed it in develop.

Question : is you app using threads ? Because without lock, it might corrupt MALT internally.

If no threads in the app, I would also deactivate two things on MALT to get a chance to pass :

1. Disable using threads for the addr2line calls : -o addr2line:threads=1
2. If you still get the previous crash, try to disable the internal allocator by add -DMALT_USE_STD_MALLOC=ON. Note it will change the memory layout of your program by mixing MALT blocks in the middle of the one from the app. And physical memory will also include the MALT memory in that case. But it still offer all the rest.
3. You can also maybe try to just apply 2. and keep the threads. The only part which is locking in loadCurrentStack is the MALT_MALLOC.

Note: I'm not 100% sure I'm not using some threads elsewhere in the last version so not 100% sure the LockDummy is usable in practice in last versions.

Question:

1. Is the original problem (deadlock) reproducable ?
2. Is it in MPI context ?
3. Any chance to get the MALT internal stack to see where I am in the tool at that deadlock ?
4. Is it python or C code ? (there are several loadCurrentStack function in MALT).