Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
26 user(s) are online (14 user(s) are browsing Forums)

Members: 1
Guests: 25

sTix, more...

Support us!

Headlines

Recent files - OS4Depot - Your one stop for AmigaOS4 files





« 1 2 3 (4)


Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/10 19:34   #61
Just popping in
Joined:
2011/7/20 20:01
From In the sticks
Posts: 98
@salass00

Quote:

'data' does not point to a floating point if that is what you mean. Instead it points to a signed 32-bit fixed point number which is converted to a float by casting and then dividing by the number FIXEDPOINT_FACTOR which is probably a power of two.


Ah yeah, that's what I meant I just wanted to get at the raw byte representation of those numbers.

   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/10 20:17   #62
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@billyfysh
I can't build that beast for win32 for now, as well as creating simple test cases, but if it auto-fixed by the compiler flags, then let it be, all fine :)

Currently, the more important problem is killthread() test not working, and I tried to deal with network-related code that crashes all ways around, which also may be affected by threading.

I will clean all the stuff and put changes on GitHub one by one, so everyone can see what was changed, etc and what bugs left, so it will be easier to follow.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/11 20:34   #63
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@all

There some progress: normal FreeType fonts now, and threaded curl working for listing for servers, etc (but still issues with connecting and creating own servers) (click open in new tab for fullsize):

Resized Image

But fighting for now with some Lua related (probably) issue. Maybe some of you can help with ideas as always.

So, visually issue happens like that: when we run the game, it on the running asks via AmigaDOS to "please insert volume" for 4 files:

menu_overlay.png:
menu_background.png:
menu_footer.png:
menu_header.png:

Resized Image


See at the end of file ":", so that why AmigaDOS ask for insert volume. That means that at the end of files somewhere in the code added ":" for some unknown reassons.

Now the logic of the game there easy: if you have a base pack of game, or additional games created, game on the running checking firstly if we have for our created games any of those 4 files (and load them if we have), and, if not, fallback to "base" ones.

That handled by this Lua script:

https://github.com/minetest/minetest/b ... tin/mainmenu/textures.lua

The issue is that everything works as expected, but we have those requesters. Files when need it found and used, and when not, then not, but in any case, we always had those requesters, and does not matter if files there, or not there. Like, it just some additional stuff happen somewhere.

After some good hours of debugging, find out that from where those functions in lua called, and find out where is roots are :

Quote:

bool PathExists(const std::string &path)
{
struct stat st{};
return (stat(path.c_str(),&st) == 0);



That is stat() when compiled with -lunix

If we compile that code:

Quote:

#include <stdio.h>
#include <sys/stat.h>

int main()
{
struct stat st{};
return (stat("work:aaaa",&st) == 0);
}



with -lunix or without , it then works as expected, no requesters.

If we compile that code:

Quote:

#include <stdio.h>
#include <sys/stat.h>

int main()
{
struct stat st{};
return (stat("/aaaa",&st) == 0);
}



Without -lunix, it also ok. But if we compile it with -lunix, then it asks for "insert volume aaaa:".

Not sure if it should react like this? At least that -lunix stuff was to help to translate Unix style patches to amiga ones..


Edited by kas1e on 2021/1/11 22:05:55
Edited by kas1e on 2021/1/11 22:18:11
Edited by kas1e on 2021/1/11 22:21:56
Edited by kas1e on 2021/1/11 22:32:25
Edited by kas1e on 2021/1/11 22:34:02
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/12 7:43   #64
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1203
@kas1e

Could it be there is some path prefix missing? Should it be like ./path/aaaa rather?

/work/aaaaa would be the same as work:aaaaa (unix vs. amiga).

I think it's normal to ask for volumes if path begins with the slash (root).
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/12 13:21   #65
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@Capehill

It's usual AmigaOS/Unix/Win32 paths mess :) Just sometimes adding -lunix deal with everything, sometimes not. And when not, you had to go through code and fix it. Or when you didn't use -lunix fix even more.

For example for now, when I remove -lunix, then it failed to do "rename()".

For example this kind of code:

#include <stdio.h>
#include <string>


int main()
{
    
    bool rename_success = false;
    
    std::string tmp_file = "work:aaaa/test.txt.~mt";
    std::string path = "work:aaaa/test.txt";
    
    rename_success = rename(tmp_file.c_str(), path.c_str()) == 0;
    
    
    if (!rename_success) {
        printf ("rename failed, damn!n");
        return false;
    } else {
        printf("rename succes, ya!n");
    }

}


Works when I compile it with -lunix, and didn't work when I compile it without -lunix. But it's pure amiga patches! How it can be that rename() didn't work when we didn't use Unix patches in and fail, like there is a wrong path? And that the same and for clib2 and for newlib.


So what to do then? Keep -linux and only workaround that "/" thing, or remove -linux, and fix one by one failed functions or whatever else where issues will popup.

With this particular "rename()" issue we can of course just use AmigaDOS Rename(), and be done with it, but is it anyway some issues in rename() implementation on both clib2 and newlib?

And by the way, seems DOS's Rename() can't overwrite a file, while clib2's and newlib's rename() can. I.e. if we have already "test.txt", and want rename some other file to "test.txt" it will not from DOS's Rename(), while clib/newlib's rename() will overwrite it.


Edited by kas1e on 2021/1/12 13:51:34
Edited by kas1e on 2021/1/12 13:54:06
Edited by kas1e on 2021/1/12 13:59:07
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/13 9:03   #66
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@All

In end i think i better go the "amiga paths" way, i.e. removing -lunix from linking line and fix amiga paths.

There from begining bunch of little problems:

1. rename() function behave differently

-- it didn't delete an exiting file with the same name to which we tried to rename
-- on posix 0 is return if succes, on amigados 0 is return if _NOT_ succes.

That how i deal with:

#ifdef __amigaos4__
    // AmigaDOS's Rename didn't overwrite an exiting destination file, so we mimic unix way: where rename() also delete a existing file with the same name.
    // On linux if rename() succes 0 is return, on AmigaDOS 0 return if rename is failed instead. So we spaw a logic a bit:
    IDOS->Delete(path.c_str());
    rename_success = IDOS->Rename(tmp_file.c_str(), path.c_str()) != 0;

    if (!rename_success) {
        warningstream << "Failed to write to file: " << path.c_str() << std::endl;
        // Remove the temporary file because moving it over the target file
        // failed.
        remove(tmp_file.c_str());
        return false;
    }
#else
    rename_success = rename(tmp_file.c_str(), path.c_str()) == 0;
    if (!rename_success) {
        warningstream << "Failed to write to file: " << path.c_str() << std::endl;
        // Remove the temporary file because moving it over the target file
        // failed.
        remove(tmp_file.c_str());
        return false;
    }
#endif


2. There were some "double slashes" in the pathes, causing by the lua scripts in the parts which load menu's textures. I think at first to fix it in lua scripts, but fixing data files kind of suck, so instead i add in the menu loading textures functions that:

#ifdef __amigaos4__
// function to replace X amount of bytes in the buffer on Y amount of byte
std::string ReplaceAll(std::string str, const std::string& from, const std::string& to) {
    size_t start_pos = 0;
    while((start_pos = str.find(from, start_pos)) != std::string::npos) {
        str.replace(start_pos, from.length(), to);
        start_pos += to.length(); // Handles case where 'to' is a substring of 'from'
    }
    return str;
}
#endif


And then, in the int ModApiMainMenu::l_set_background(lua_State *L)

.....bablla ......


    if (!lua_isnone(L, 4)) {
        minsize = lua_tonumber(L, 4);
    }

#ifdef __amigaos4__

// fix "//" in the paths.
// when compiling withot -lunix (for use amigados native paths), then "//" things will handled wrong.
// so find out if we had "//" in the path and replace it with one "/"

    texturename = ReplaceAll(texturename, std::string("//"), std::string("/"));

    printf(" after fix texturename = %sn",texturename.c_str());
    
#endif


    if (backgroundlevel == "background") {
        retval |= engine->setTexture(TEX_LAYER_BACKGROUND, texturename,
                tile_image, minsize);
    }

.... blalba...





3. RecursiveDelete() function (to delete created games) were written for win32 and for posix (with fork + rm -rf), so i go win32 way:

https://github.com/minetest/minetest/b ... ster/src/filesys.cpp#L126

And replace it like that

#ifdef __amigaos4__

// Delete() on AmigaDOS return 0 if fail,  and DeleteFile() on win32 return 0 if success, so change it as well.

bool RecursiveDelete(const std::string &path)
{
    infostream << "Recursively deleting "" << path << """ << std::endl;
    if (!IsDir(path)) {
        infostream << "RecursiveDelete: Deleting file  " << path << std::endl;
        if (IDOS->Delete(path.c_str())) {
            errorstream << "RecursiveDelete: Failed to delete file "
                    << path << std::endl;
            return false;
        }
        return true;
    }
    infostream << "RecursiveDelete: Deleting content of directory "
            << path << std::endl;
    std::vector<DirListNode> content = GetDirListing(path);
    for (const DirListNode &n: content) {
        std::string fullpath = path + DIR_DELIM + n.name;
        if (!RecursiveDelete(fullpath)) {
            errorstream << "RecursiveDelete: Failed to recurse to "
                    << fullpath << std::endl;
            return false;
        }
    }
    infostream << "RecursiveDelete: Deleting directory " << path << std::endl;
    if (IDOS->Delete(path.c_str())) {
        errorstream << "Failed to recursively delete directory "
                << path << std::endl;
        return false;
    }
    
    return true;
}
#endif


Not sure how correct is that, but works.

So, now we can run without -lunix, and all seems loads correctly, no requests, games can be created/deleted/etc.


Edited by kas1e on 2021/1/13 20:41:01
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/13 20:42   #67
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@All
After we can loads fine with no -lunix, and no requesters appear and all seems to works correctly (in the menu, at least), the real problem is left: I can't connect to any server (just disconnected), and can't create my own server (going to "wait for the threads" busy looping).

IMHO that all related to remaining threading issues, and even if not, IMHO first step is to solve an issue with KillThread() unit-tests, which is here:

https://github.com/minetest/minetest/b ... t/test_threading.cpp#L114

And then once it works, and it didn't fix issues with the network, then going further. But with failing tests we for sure can't move deeper.

Have anyone any ideas about it? I will try to put all the debug info everywhere in meantime.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/13 21:29   #68
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@All

So that what happen when we just tried to pass KillThread() test:

I put printfs all over the ways in test-function inself:

void TestThreading::testThreadKill()
{
    SimpleTestThread *thread = new SimpleTestThread(300);

    printf("1n");
    UASSERT(thread->start() == true);

    // kill()ing is quite violent, so let's make sure our victim is sleeping
    // before we do this... so we don't corrupt the rest of the program's state
    printf("2n");
    sleep_ms(100);
    printf("3n");
    UASSERT(thread->kill() == true);

    printf("4n");
    // The state of the thread object should be reset if all went well
    UASSERT(thread->isRunning() == false);
    printf("5n");
    UASSERT(thread->start() == true);
    printf("6n");
    UASSERT(thread->stop() == true);
    printf("7n");
    UASSERT(thread->wait() == true);

    printf("8n");
    // kill() after already waiting should fail.
    UASSERT(thread->kill() == false);

    delete thread;
}


What we see in the console output that it's: 1,2,3 and never 4 or more.

On the serial with adding prints to our threading implementation we have that:

Quote:

Before ObtainSemaphore in __gthread_create
After ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread

... busy forever ...


All is see is that first UASSERT(thread->kill() == true); didn't works.

And their kill() are there:

https://github.com/minetest/minetest/b ... threading/thread.cpp#L139

I put prinfs all over it as well, like this:

bool Thread::kill()
{
    if (!m_running) {
        printf("from kill() 1n");
        wait();
        return false;
    }

    printf("from kill() 2n");
    m_running = false;

    printf("from kill() 3n");
#if defined(_WIN32)
    // See https://msdn.microsoft.com/en-us/libra ... ead__native_handle_method
    TerminateThread((HANDLE) m_thread_obj->native_handle(), 0);
    CloseHandle((HANDLE) m_thread_obj->native_handle());
#else
    // We need to pthread_kill instead on Android since NDKv5's pthread
    // implementation is incomplete.
# ifdef __ANDROID__
    pthread_kill(getThreadHandle(), SIGKILL);
# else
    printf("from kill() 4n");
    pthread_cancel(getThreadHandle());
# endif
    printf("from kill() 5n");
    wait();
#endif

    printf("from kill() 6n");
    m_retval       = nullptr;
    m_joinable     = false;
    m_request_stop = false;

    return true;
}


And we can see 2,3,4,5, but not 6. Meaning that the last wait() executed and we didn't go futher.

So i added debug prinfs to their wait() as well, like that:

bool Thread::wait()
{
    printf("wait 1n");
    MutexAutoLock lock(m_mutex);

    printf("wait 2n");
    if (!m_joinable)
        return false;


    printf("wait 3n");
    m_thread_obj->join();

    printf("wait 4n");
    delete m_thread_obj;
    m_thread_obj = nullptr;

    printf("wait 5    n");
    assert(m_running == false);
    m_joinable = false;
    
    printf("wait 6n");
    return true;
}


And as a result, we have there: 1,2,3, and never 4. So, join() fail, again our majesty join() :)




In summary what we have with that test: test start a thread, then wait a bit, and send kill. Kill is just called pthread_cancel and then call internal wait() which check: if not joinable, then return false, but if joinable then tried to join. And we fail to join there with our forever busy "waiting for a thread" from native implementation.





Edited by kas1e on 2021/1/13 21:49:29
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/14 10:59   #69
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1775
@kas1e

I rewrote my posix semaphore implementation as a static library so it can more easily be linked to a program and only the needed functions will be used.

https://www.dropbox.com/s/lwbg2fbefgaoy6g/libpsem.7z?dl=0
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/14 11:10   #70
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1775
@kas1e

To stop another thread in a clean way on AmigaOS requires co-operation from the thread that is to be stopped, but the kill operation has to do this by force because of how it is designed.

It would be better if MineCraft used a semaphore or other similar construct to signal the threads to stop and then used join to wait for them to end similar to the SimpleThreadTest here:

https://github.com/minetest/minetest/b ... ittest/test_threading.cpp
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/14 16:58   #71
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@Salas00
Quote:

I rewrote my posix semaphore implementation as a static library so it can more easily be linked to a program and only the needed functions will be used.


Oh cool! Can be used and with c and with c++ I assume with no probs?

Quote:

To stop another thread in a clean way on AmigaOS requires co-operation from the thread that is to be stopped, but the kill operation has to do this by force because of how it is designed.


Maybe that was the reason why they remove this "kill" thing from code lately: https://github.com/minetest/minetest/c ... fd54125c4199a16ac03b5ceff

So they remove the whole "kill()", a test case for, but still as you can see keep that "pthread_chancle + wait()" at the end of the destructor, which means it will the same halt for us. Just with testkill() test, I assume it can be easier to check when it works...

I don't use the very latest code of Minecraft, as the last one brings some new errors, so I stick for now with 5.0.1, but can easily replace threading the same as they have in the latest code. But then, this "pthread_cancel(getThreadHandle()); + wait()" still in their destructor, so will hangs the same when they want to "kill" threads.

If you have an idea on how to rewrite their Thread::~Thread() (or whole threading.cpp) so it will works as need it on amigaos4, i surely can happy donate a bit with no probs :)

PS. I currently clone to my Github 5.0.1 version and start adding amigaos4 changes, so hope today/tomorrow will be at the same sync with my current local code, so everyone can see what i change and how code looks like , etc.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/14 20:10   #72
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@Salas00 (and all)

Created a repo there: https://github.com/kas1e/minetest

Added all the fixes and stuff, plz check the history of commits just to see what I change, etc. Also already used there -lpsem , and that much better indeed. Can you maybe upload it on os4depot as well, like a usual SDK (i.e. semaphore in the SDK/local/newlib/include, libpsem.a to SDK/local/newlib/lib) , so we can just write in the README.md about AmigaOS4 build instructions that posix-semaphore library need to be download from os4depot, etc.

The only 1 thing that remains to commit is changes about getting rid of ipv6 support + custom GAI code (for those getaddrinfo/freeaddrinfo, etc), so I want to make them clean and via #ifdef __ipv6_build__ so in the commit history everything will be visibly well, and we can see if it's me fucked up something with network code, or still some other work needs to be done. Hope to do it tomorrow, just to not mess things today.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/15 7:34   #73
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@Salas00
I go a more easy way with network code: just added dummy defines/structs for ipv6, so code compiles without changes, just in one header file those dummies, see

https://github.com/kas1e/minetest/comm ... c52a7f97c2f20cfad5b8efc5f

In the config file of the game, we do have "enable_ipv6=false", so this code of no use, but everything compiles without too many ifdefs everywhere. At least for now, for a start.

I also had to use my own "gai" library to make freeaddr/getinfoaddr/gai_stderr/etc works.

Now, when i tried to connect to any server or create my own one, then 50% of times we simple lockup. And 50% of time, we crash in the resolve function:

https://github.com/kas1e/minetest/blob ... /network/address.cpp#L114

Which can happen easily due to my custom "gai" library and maybe dues to the code itself (i don't like that part where they Address::serializeString()).
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/15 11:06   #74
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@salas00
After putting prinfs with delays to resolver function, it seems that this one is fine. Things just lockup (i.e. crashes on serial, but visully lockup, with almost no crashlog on serial, just a little bit). And on serial it looks like this:

Waiting for thread
Before ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Waiting for thread
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
kernel 54.31 (5.1.2021) AmigaOne X5000 release
Machine model: 9 (AmigaOne X5000/20)
Dump of context at 0xEFDFC3E0
Trap type: DSI exception
DSISR: 00800000  DAR: 0000636C
No matching page found
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: in module kernel+0x00052FD0 (0x01852FD0)
Crashed process: minetest (0x6802FD80)
DSI verbose error description: Access to address 0x0000636C not allowed by page protection in user state (protection violation)
Access was a store operation
Exception Syndrome Register: 0x00800000
 0: 0184AA8C 6387CA10 00000002 00006368 0000000C 00000000 00000030 6387CAE0
 8: 02231CC0 0000000C ABADCAFE 1515EF18 3B353935 63895E40 6387CCB8 6387CD48
16: 5FFF43BC 1515E360 FD209660 00000000 0223B136 02230000 02230000 02008418
24: 0239ECC2 02230000 EFFF6944 63707098 63837FDC 0000636C EFFF6900 0223A968
CR: 55353595   XER: A000007E  CTR: 0000000C  LR: 0184AAC8

Disassembly of crash site:
 01852FC0: 5529F0BE   rlwinm            r9,r9,30,2,31
 01852FC4: 614ACAFE   ori               r10,r10,51966
 01852FC8: 39290001   addi              r9,r9,1
 01852FCC: 7D2903A6   mtctr             r9
>01852FD0: 95430004   stwu              r10,4(r3)
 01852FD4: 4200FFFC   bdnz+             0x1852FD0
 01852FD8: 4E800020   blr
 01852FDC: 5484F0BF   rlwinm.           r4,r4,30,2,31
 01852FE0: 4DC20020   beqlr-
 01852FE4: 5489103A   rlwinm            r9,r4,2,0,29
msr: 0x0002B032
TLB1 (64 entries):
 * [ 52]: size=7 tid = 0 TS = 1 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
 * [ 53]: size=6 tid = 0 TS = 1 epn=0x01000000 rpn=0x00000000_01000000 WIMG=0x0 XXWWRR=0x5 protected
 * [ 54]: size=6 tid = 0 TS = 1 epn=0x01400000 rpn=0x00000000_01400000 WIMG=0x0 XXWWRR=0x5 protected
 * [ 55]: size=6 tid = 0 TS = 1 epn=0x01800000 rpn=0x00000000_01800000 WIMG=0x0 XXWWRR=0x33 protected
 * [ 56]: size=6 tid = 0 TS = 1 epn=0x01C00000 rpn=0x00000000_01C00000 WIMG=0x0 XXWWRR=0x33 protected
 * [ 57]: size=6 tid = 0 TS = 1 epn=0x02000000 rpn=0x00000000_02000000 WIMG=0x0 XXWWRR=0xF protected
 * [ 58]: size=4 tid = 0 TS = 1 epn=0x02400000 rpn=0x00000000_02400000 WIMG=0x0 XXWWRR=0xF protected
 * [ 59]: size=3 tid = 0 TS = 1 epn=0x02440000 rpn=0x00000000_02440000 WIMG=0x0 XXWWRR=0xF protected
 * [ 60]: size=3 tid = 0 TS = 1 epn=0x02450000 rpn=0x00000000_02450000 WIMG=0x0 XXWWRR=0xF protected
 * [ 61]: size=7 tid = 0 TS = 0 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
 * [ 62]: size=A tid = 0 TS = 0 epn=0x00000000 rpn=0x00000000_00000000 WIMG=0x0 XXWWRR=0x3F protected
 * [ 63]: size=A tid = 0 TS = 0 epn=0x40000000 rpn=0x00000000_40000000 WIMG=0x0 XXWWRR=0x3F protected
HAL_MaxTLB = 51, HAL_NextTLB = 0
MMUCFG = 0x064809C4
mas0 = 0x103F0000
mas1 = 0xC0000A00
mas2 = 0x40000000
mas3 = 0x4000003F
mas4 = 0x00000100
mas5 = 0x00000000
mas6 = 0x00000001
mas7 = 0x00000000
mas8 = 0x00000000

Kernel command line: serial munge debuglevel=1

Registers pointing to code:


The same when I tried to create my own server:

Waiting for thread
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
kernel 54.31 (5.1.2021) AmigaOne X5000 release
Machine model: 9 (AmigaOne X5000/20)
Dump of context at 0xEFDFC3E0
Trap type: DSI exception
DSISR: 00800000  DAR: 00006F8B
No matching page found
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: in module kernel+0x00052FD0 (0x01852FD0)
Crashed process: minetest (0x6802FD80)
DSI verbose error description: Access to address 0x00006F8B not allowed by page protection in user state (protection violation)
Access was a store operation
Exception Syndrome Register: 0x00800000
 0: 0184AA8C 63897410 00000002 00006F87 0000000C 00000000 00000030 638974E0
 8: 02231CC0 0000000C ABADCAFE 8000000F 37355595 638AFE40 63763863 00000003
16: FFFFFFFF 63763840 63763862 00000000 0223B136 02230000 02230000 02008418
24: 0239ECC2 02230000 EFFF6944 6F8BF510 63852FDC 00006F8B EFFF6900 0223A968
CR: 55353595   XER: A000007E  CTR: 0000000C  LR: 0184AAC8

Disassembly of crash site:
 01852FC0: 5529F0BE   rlwinm            r9,r9,30,2,31
 01852FC4: 614ACAFE   ori               r10,r10,51966
 01852FC8: 39290001   addi              r9,r9,1
 01852FCC: 7D2903A6   mtctr             r9
>01852FD0: 95430004   stwu              r10,4(r3)
 01852FD4: 4200FFFC   bdnz+             0x1852FD0
 01852FD8: 4E800020   blr
 01852FDC: 5484F0BF   rlwinm.           r4,r4,30,2,31
 01852FE0: 4DC20020   beqlr-
 01852FE4: 5489103A   rlwinm            r9,r4,2,0,29
msr: 0x0002B032
TLB1 (64 entries):
 * [ 52]: size=7 tid = 0 TS = 1 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
 * [ 53]: size=6 tid = 0 TS = 1 epn=0x01000000 rpn=0x00000000_01000000 WIMG=0x0 XXWWRR=0x5 protected
 * [ 54]: size=6 tid = 0 TS = 1 epn=0x01400000 rpn=0x00000000_01400000 WIMG=0x0 XXWWRR=0x5 protected
 * [ 55]: size=6 tid = 0 TS = 1 epn=0x01800000 rpn=0x00000000_01800000 WIMG=0x0 XXWWRR=0x33 protected
 * [ 56]: size=6 tid = 0 TS = 1 epn=0x01C00000 rpn=0x00000000_01C00000 WIMG=0x0 XXWWRR=0x33 protected
 * [ 57]: size=6 tid = 0 TS = 1 epn=0x02000000 rpn=0x00000000_02000000 WIMG=0x0 XXWWRR=0xF protected
 * [ 58]: size=4 tid = 0 TS = 1 epn=0x02400000 rpn=0x00000000_02400000 WIMG=0x0 XXWWRR=0xF protected
 * [ 59]: size=3 tid = 0 TS = 1 epn=0x02440000 rpn=0x00000000_02440000 WIMG=0x0 XXWWRR=0xF protected
 * [ 60]: size=3 tid = 0 TS = 1 epn=0x02450000 rpn=0x00000000_02450000 WIMG=0x0 XXWWRR=0xF protected
 * [ 61]: size=7 tid = 0 TS = 0 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
 * [ 62]: size=A tid = 0 TS = 0 epn=0x00000000 rpn=0x00000000_00000000 WIMG=0x0 XXWWRR=0x3F protected
 * [ 63]: size=A tid = 0 TS = 0 epn=0x40000000 rpn=0x00000000_40000000 WIMG=0x0 XXWWRR=0x3F protected
HAL_MaxTLB = 51, HAL_NextTLB = 0
MMUCFG = 0x064809C4
mas0 = 0x103F0000
mas1 = 0xC0000A00
mas2 = 0x40000000
mas3 = 0x4000003F
mas4 = 0x00000100
mas5 = 0x00000000
mas6 = 0x00000001
mas7 = 0x00000000
mas8 = 0x00000000

Kernel command line: serial munge debuglevel=1

Registers pointing to code:
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)


See in that one we even after the crash continues to receive to serial log an info from threads.

So it seems that something goes wrong with threads still. The network code of Minecraft is mostly 3 files:

src/network/address.cpp
src/network/socket.cpp
src/network/connectionthreads.cpp

And seems for each operation it spawn a thread, etc. So after the "resolving" thread finished (and with correct values) it should start to connect to the server, but fail for some reasons (and as I can see, quite random ones, which may prove that there mess with threads going on).
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: MineCraft (MineTest) work in progress help need it
Posted on: 1/16 10:24   #75
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6707
@Salas00
Thanks for the os4depot upload! Added that to the amigaos4 build part: https://github.com/kas1e/minetest#amigaos4-instructions

So now everyone can build it once meet the requirements.

The only problem now is all that network code. Maybe in end, it's all matter of the src/network/connectionthreads.cpp ?

Just strange why it that randomly crashes/lockups when about to create a server or to connect to a server (so after resolve done, and then). And what I noticed that when I put Delays() to Resolve() when checking it, those Delays make Resolve() not crashes. Like, separate threads don't interact well with together and didn't know what/when one finished. But that only a guess...


I even tried to replace all sys/socket.h includes to sys/bsdsocket.h in all the source files in whole Minecraft code, so to use directly roadshow and not newlib, but still have exactly the same issues.

@All

Have anyone any idea how to debug it further now?



Edited by kas1e on 2021/1/16 11:06:10
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 2 3 (4)



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project