MineCraft (MineTest) work in progress help need it

@kas1e

Quote:
Ah, so it doesn't have the history behind it that I was expecting. Still, from at least a casual examination of the code, I don't see anything that looks like it would cause a major system lockup, as long as it's getting valid data to work with. That's not the same as saying I'm sure there's nothing wrong with it, but I'd still check those other two possibilities first.

Quote:
Having a working debugger would be nice, though a hard system crash would probably kill the debugger, too.

Unfortunately, there's no simple way to check for the first possibility (corruption of the underlying sem_t). The sem_t contains embedded Exec SignalSemaphore and List structs, rather than pointers to them, so you'd need to DebugPrintF() a bunch of fields in those structs to try to determine if they are corrupt or not. You could at least dump isem->value and see if it looks reasonable (it should probably be zero).

You could also add some "made it to this point"-style DebugPrintF()s inside sem_post(), to try to determine where in that function the crash occurs.

For the second possibility (the code being triggered by the semaphore is what crashes) you'd need to locate the code that's waiting on the semaphore that's being posted to; something like "m_send_sleep_semaphore.wait()". Then you could add some "made it to this point"-style DebugPrintF()s both before and after the wait, to see if the code actually exits the wait before the crash occurs. If it does, you can move the DebugPrintF()s further along in the code to try to narrow down where the crash happens.

@msteed
Thanks! Will test both ways!

Regarding semaphores in general: i talked with Andrea (who workign now on clib2) , and some time ago he had some problem with Semaphores too, when InitSemaphores on semaphore is not created with AllocVecTags. I.e. now in our sem_init() from libpsem is:



But what Andrea mean it should be something like :



etc.

Through we test this way, and i have even more crashes even when just testing pure threading code without network involved, so that need invistigating.

For now will try to debug 2 possibilities about which you talk about.


EDIT: on of minetest authors says "Yes, it sounds like you need to find out what's wrong with your semaphore implementation before Minetest can start working correctly. If you have C++20 support in your toolchain you could look up std::counting_semaphore and compare its implementations."

Not sure through how/what it mean

@kas1e

I'd assume that for compatibility reasons malloc() uses MEMF_SHARED. If it didn't, you'd expect to get a DSI when some other task/thread tried to access the semaphore.

Quote:
You could also allocate the entire isem_t using AllocVecTags(), instead of just the SignalSemaphore. That way, you wouldn't need to change any of the other semaphore code to work with pointers to objects instead of embedded objects (I assume you made those changes when you tested Andrea's suggestion).

SignalSemaphores (and Lists) can also be allocated using AllocSysObjectTags(), which presumably initializes them for you. You'd again be working with pointers to objects.

I suspect that none of that will make a difference, but it might be worth a try if further debugging doesn't turn up anything.

Quote:
It sounds like they're suggesting that if we have a working implementation of std::counting_semaphore (do we?) that we could look at the source code for that and see how it's implemented compared to how libpsem did it.

Any News on MineTest?