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?

@kas1e

Is this still stuck in the same spot? Just curious if any further progress had been made. Thanks!

-- eliyahu

@eliyahu
Yeah, same issue as it was : something wrong with network threading, as explained above. Someone with more skills need it willing to dig in into

@kas1e
Quote:The AmiTCP API doesn't support threading at all: You have to open an own instance of SocketBase and ISocket in each thread, and it has to be a DOS Process, exec Tasks are not supported.
But if you do it that way you can't share any socket FDs between the threads.

RoadShow has an extension which allows sharing ISocket and the socket FDs (SBTC_CAN_SHARE_LIBRARY_BASES). newlib is using it of course, but for clib2 the default is (or at least was 20 years ago) to build a useless single-threading version of the C library, only if it's built with -D__THREAD_SAFE enabled the network (and several other) functions can work when using threads.

Hi there!

Can I have a try on my configuration ?

Pegasos 2, 1024 RAM, G4, Radeon 9250, AmigaOs 4.1 Fe Update 2

Thumbs up for the project :)

@Mabo
There are nothing to try :) If you read the whole topic, you will find where and why port stops.

In brief, the issue is that Minetest seems to be used in some sort of threaded network code, which fail on us for unknown reasons. From time to time i tried to build it with updated SDK, or updated binutils/gcc/clib2 , but so far no luck to make it works. Network based code always crashed. And the entire game builds like this : no working network, no working game.

Also, for pegasos2 it will be no go even if it will works someday: because it uses GL4ES, which mean you need working Warp3DNova and Ogles2, but pegasos2 currently can't handle RadeonHD/RX where Wap3dNova/Ogles2 works, so, at least until bridges/radeonhd-rx cards not works on pegasos2's kernel, peg2 users will be out of luck with any gl4es based ports.

@kas1e

tysm for the full explenation ^^

As far as i know there are some RadeonHD via AGP :/

Is there any chance that minetest could be played as a single player bypass the network requirements?

What is the difference between your port and the old AmicraftNova ?

Bye and good luck ò/

@Mabo
Quote:
That 2 different games. AmicraftNova is just written from scratch for os4 only, while Minetext is port of well-known Minecraft clone:
https://www.minetest.net/

@kas1e
What are the min. requirements?

@Reynolds
Quote:

If it will ever work for us (i.e. threading-network-crash issues will be dealt with) then it will be working warp3dnova and ogles2 library the only requirements.

But, as i say in previous post to Mabo: there are nothing for now, but only a menu shown. Game didn't work, and crashes in network based code, see post #109 (or better last few pages of topic).