I just tried your new semaphore code without new debugs at first: and it passed that damn atomicsemaphore test! That how it looks like now :
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) 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 ObtainSemaphore in __gthread_create after findtask + strcutprocess_userData , but before Wait for the parent task after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F) 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) Before ObtainSemaphore in __gthread_entry Before ObtainSemaphore in __gthread_entry After ObtainSemaphore in __gthread_entry After ObtainSemaphore in __gthread_entry Before ObtainSemaphore in __gthread_entry Before ObtainSemaphore in __gthread_entry After ObtainSemaphore in __gthread_entry After ObtainSemaphore in __gthread_entry
And that how it looks like from our debugs when we run test units (for both tests now):
Quote:
======== Testing module TestThreading before join so we try to join() after join before join so we try to join() after join before join so we try to join() after join before join so we try to join() after join before join so we try to join() after join [PASS] testStartStopWait - 591ms we in the testAtomicSemaphoreThread first for() count = 0 before thread = new AtomicTestThread(val, trigger); thread->start seems fine too first for() count = 1 before thread = new AtomicTestThread(val, trigger); thread->start seems fine too first for() count = 2 before thread = new AtomicTestThread(val, trigger); thread->start seems fine too first for() count = 3 before thread = new AtomicTestThread(val, trigger); thread->start seems fine too
before trigger.post(num_threads); after trigger.post(num_threads);
Second for() count = 0 before thread->wait before join so we try to join() after join before delete thread Second for() count = 1 before thread->wait before join so we try to join() after join before delete thread Second for() count = 2 before thread->wait before join so we try to join() after join before delete thread Second for() count = 3 before thread->wait before join so we try to join() after join before delete thread [PASS] testAtomicSemaphoreThread - 193ms ======== Module TestThreading passed (0 failures / 2 tests) - 786ms
So, that means that to the Adtools repo we need to commit just one fix about the first test: in __gthread_mutex_trylock add missing mx->u.i.acquired++; before return 0 at the end.
Can you do plz so you already set up Github stuff for adtools and already merge the previous fix? (and Sebastian will for sure accept it from you fast).
As for other issues I had:
When trying to choose in "join game" any server, it didn't connect but exit back.
Also, when I tried to connect to the game I create, then have:
Quote:
ERROR[Main]: ModError security: Blocked attempted to read from /Work/minetest/builtin/common/strict.Lua ERROR[Main]: Check debug.txt for details. ACTION[Main]: Server: Shutting down
This one I fixed by set secure.enable_security = false in config.
But then create my own server and connect to just cause crash in ServerStart(), damn :)
I then run all the command line tests , and find out those still fail:
module TestServerModManager :
functions testGetModWrongDir(), testGetMods(), testGetModspec(), testGetModNamesWrongDir(), testGetModNames() and testGetModMediaPathsWrongDir().
module TestSerialisation :
functions testStreamRead() and testBufReader()
All other tests seem passed well.
On the running I have also that:
"please insert volume minetest_menu_footer.png in any drive" and "please insert volume minetest_menu_header.png in any drive"
Those ones about amiga paths, but I build the whole thing with -Linux, and those seem can come from Lua scripts (though I didn't find anything about those names in). And doing a search in the whole minetest directory didn't show me any files with such names. So it seems those file names "Constructs" somehow from lua scripts or so ..
I need now double-check everything and sorting all issues better. But we very close now!
Thank you a bunch as always, some donation will find a way you to as well soon! (btw, part of the donations I made also come from Skateman, so it not only me :) )
Edited by kas1e on 2021/1/7 15:09:00 Edited by kas1e on 2021/1/7 15:10:32
Try printing the float number generated by readF1000(is) and if it's close enough to 53.534 you can just disable the assert.
BTW for gcc >= 4.8 you can change the bswap macros to: #define __bswap_16(x) __builtin_bswap16(x) #define __bswap_32(x) __builtin_bswap32(x) #define __bswap_64(x) __builtin_bswap64(x)
With readU16(is) == 0xF00D thigs even worse, if i printf on our side like: printf("test readu16 : %04X\n", readU16(is)); then i have 01F4 , kind of different..
For that one saying "Caigh unhandled exception: deSerializeString: couldn't read all chars".
Now question is, if all those things in the test didn't passed as expected, can it be the cause of bugs in the game/parsing_data/etc ? Just too much fail. Those ones all fail:
// Verify the offset and data is unchanged after a failed read
size_t orig_pos = buf.pos;
u32_data = 0;
UASSERT(buf.getU32NoEx(&u32_data) == false);
UASSERT(buf.pos == orig_pos);
UASSERT(u32_data == 0);
// Now try the same for a failed string read
UASSERT(buf.getStringNoEx(&string_data) == false);
UASSERT(buf.pos == orig_pos);
UASSERT(string_data == "");
// Now try the same for a failed string read
UASSERT(buf.getWideStringNoEx(&widestring_data) == false);
UASSERT(buf.pos == orig_pos);
UASSERT(widestring_data == L"");
UASSERT(buf.getU16() == 0xF00D);
UASSERT(buf.remaining() == 0);
Just too much, I fear we can't ignore them (or can ?)
So seems the first printf already did what it should do with "is", and then all next tests with deSerializeString fail. But if I remove that printf, then your version passed fine.
@billyfish
tried your example with cout, and it says that says of "foobar!" is 7 bytes. So that as expected, but still pure UASSERT(deSerializeString(is) == "foobar!"); fail, why ?:)
Ops, it seems it all false alarm, sorry for loosing your time on things which different.
Issue is that their foobar assert works too. It just me messing things up in "C" terms, i didn't see/noticed that i should use this "is" thing at least one time when i comment out failed one. So, deSerializeString(is) stuff surely works.
Now, when I correctly replace nonworking one by one with printf (so, this "IS" thing is used and for next tests going to be ok), i have found that we have only 3 tests failed in the testStreamRead():
So everything is about the same in both tests: F1000 + f32data.
Can we somehow tell the compiler to change the behavior with those floats, or it impossible? I mean, can we something to do automatically, so tests in those regards will be passed fine, and so the game's code will not fail in those places?
Seems we not fully done with that damn threading stuff: i find out in previous sources there was a testThreadKill() which they remove from tests after for some reasson , but which one i have in my sources:
So, when I activate this one it also halts forever in the "Waiting for thread" loop. And line after which i never had any prinf is : UASSERT(thread->kill() == true);
On serial at this time i have:
Quote:
Before ObtainSemaphore in __gthread_create after findtask + strcutprocess_userData , but before Wait for the parent taskAfter ObtainSemaphore in __gthread_create 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 Waiting for thread Waiting for thread Waiting for thread
Maybe it just "kill" function need to be fixed for os4 as well? They probably remove it lately from the test units because tested it well, but while the "kill" functionality of the threading still in their sources even today, and that didn't work for us, it can cause some problems with the game for sure.
On our side is pthread_cancel(getThreadHandle()); called, but i also tried pure "wait()" - same result. UASSERT(thread->kill() == true); never passes. And we come to that never endina "Waiting for thread" loop.
I also switched now to the latest sources of minecraft (so avoid any possible issues with 3 years old version we testing now). And they add sem_trywait() which we didn't have in our posix_semaphores. See how they use it in semaphore.cpp
int ret;
if (time_ms > 0) {
struct timespec wait_time;
struct timeval now;
if (gettimeofday(&now, NULL) == -1) {
std::cerr << "Semaphore::wait(ms): Unable to get time with gettimeofday!" << std::endl;
abort();
}
And tell us what their, ours and the raw values are for the values that fail the asserts? I just want to check what the raw byte values are to see if that helps. They should all be IEEE 754 values, I just want to check.
FWIW comparing floating point values with == is a bad idea anyway, they should really be checking that the two values are within a specified tolerance of each other. The thing is this tolerance is dependent on how big the values are in the first place due to the way that floating point values are stored in memory.
And tell us what their, ours and the raw values are for the values that fail the asserts? I just want to check what the raw byte values are to see if that helps. They should all be IEEE 754 values, I just want to check.
'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.