Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
37 user(s) are online (21 user(s) are browsing Forums)

Members: 2
Guests: 35

VooDoo, musashi5150, more...

Headlines

 
  Register To Post
« 1 ... 3 4 5 (6)

Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


See User information
@kas1e

Quote:
I never use anywhere posix semaphores, it is first time i meet with them in minetest. Frederik made this library exactly when i ask about in this thread and then fixing it few times.

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:
Question is how to find it without debugger, what to prinfs and where.

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.

Go to top
Re: MineCraft (MineTest) work in progress help need it
Home away from home
Home away from home


See User information
@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:

int sem_init(sem_t *semint psharedunsigned int value)
{
    
isem_t *isem;

    
isem malloc(sizeof(isem_t));
    if (
isem == NULL)
    {
        
errno ENOMEM;
        return -
1;
    }

    
IExec->InitSemaphore(&isem->accesslock);
    
IExec->NewList(&isem->waitlist);
    
isem->value value;

    *
sem isem;
    return 
0;
}


But what Andrea mean it should be something like :

isem->accesslock AllocVecTags(sizeof(isem->accesslock), AVT_TypeMEMF_SHAREDTAG_DONE);
    if (
isem->accesslock == NULL) {
        
__set_errno(ENOMEM);
        RETURN(-
1);
        return -
1;
    }

    
InitSemaphore(isem->accesslock);


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


Edited by kas1e on 2022/5/13 8:43:08
Go to top
Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


See User information
@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:
But what Andrea mean it should be something like :

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:
Not sure through how/what it mean

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.

Go to top
Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


See User information
Any News on MineTest?

OS4 Betatester

X1000
X5000/40
Go to top

  Register To Post
« 1 ... 3 4 5 (6)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project