@kas1e

Unless I've misunderstood your debug output then all four threads have received the CTRL-F signal.

The problem seems to be that only one of them manages to return from "thr->result = thr->entry(thr->args);" as there is only one message "Before ObtainSemaphore in __gthread_entry"
in output.

Maybe there is some problem with the atomic type that causes it to deadlock?

Edit: No I think the problem is that sem_post() (trigger.post() in TestThreading::testAtomicSemaphoreThread()) only successfully triggers one of the threads.

Could you maybe add some debug output around trigger.wait() to check this?

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

@kas1e

Try adding some debugs around the ObtainSemaphore() call in __gthread_entry():
https://github.com/sba1/adtools/blob/m ... s-thread-model.patch#L917

If the CTRL-F signal doesn't get sent it might be because the semaphore is being held by another process.

@kas1e

No, the one line 416 (try changing "int finished;" to "volatile int finished;"):

https://github.com/sba1/adtools/blob/m ... s-thread-model.patch#L416

@kas1e

The finished field in struct threadentry may have to be made volatile. Otherwise the compiler will probably read it only once at the beginning of the loop and then assume that it will never change.

@kas1e

Try changing the value of DEFAULT_ENCODING from "WCHAR_T" to "UCS-4" or "UCS-4BE".

@kas1e

If you compile semaphore.c as C++ (using g++ instead of gcc) you need to remove the 'extern "C" { ... }' from semaphore.h as well.

@kas1e

That's because you use g++ on non-C++ code.

@kas1e

I made some code fixes and added the sem_destroy() and sem_timedwait() functions.

Because sem_init() doesn't allocate anything the sem_destroy() is not needed and can be implemented as a no-op.

Link is same as above:
https://www.dropbox.com/s/43b4g16kvhd7 ... emaphore-amigaos4.7z?dl=0

You can find my fixed gcc 8 at:

https://github.com/salass00/adtools

It works with kas1e's test program.

I've also created a pull request to the original adtools repo as I said I would.

@kas1e

I wrote a quick posix semaphore implementation for a game port that I haven't finished.

As I didn't get the game fully compiled it is completely untested.

You can find the code for it here:

https://www.dropbox.com/s/43b4g16kvhd7 ... emaphore-amigaos4.7z?dl=0

I'm not sure if the locking in sem_getvalue() is needed. I added it just to be safe, but this particular operation doesn't really seem safe to me even with the locking (because of multitasking there is no guarantee that the value is still correct after the function has returned).

@afxgroup

I'm using Google Chrome with AdBlockPlus. It hasn't stopped me from commenting before, but I guess it could be the reason.

I'm going to try building a fixed gcc 8 first, and if that works out then I will try to generate an updated patch and create a pull request to the sba1/adtools repo.

@kas1e

Github won't let me comment on the issue so I will write my findings here for now (It keeps saying "You can't comment at this time."):

Looking at the code in gthr-amigaos-native.c the problem is that init_threadstore() has not been called yet so when __gthread_self() tries to obtain the semaphore &threadstore->sem it leads to a NULL pointer access.

A quick fix would probably be to add the line:
__gthread_once (&threadstore_once, init_threadstore);

in __gthread_self() just after:
__gthread_once (&libs_once, init_libs);

Same as how it is done in the __gthread_create() function.

@Rigo

It's listed under "AmigaOS system updates", so it's from the update.amigaos.net server.

As I used my FE update 1 install for this test I only have two servers configured: amiupdate.codebench.co.uk (3rd party) and update.amigaos.net.

@Rigo

https://www.dropbox.com/s/p5wtlkbvt05z ... ntribution-21.10.png?dl=0

Locale file date is 18.12.2020 and remote file date is 21.12.2020.

@Sbaitso

Quote:

It is because the date in the AmiUpdate database is not set correctly.

If you select the update and press "Info" you can see that the remote and local version numbers are the same and only the date differs.

@pjs

It's because the freedb.org server used by ADRipper has been shut down.

See post from trixie here:
https://www.amigans.net/modules/xforum ... id=121295#forumpost121295

@salass00

Quote:

Not quite that simple unfortunately. I added a NULL pointer check in CloseElf() but it just lead to a different DSI (again caused by a NULL pointer access) in a different function, but still from a call to IElf->CloseElfTags() from hieronymus:Bosch_StopAcquisition().

@corto

I just tried to use hieronymus on my Sam460 and it crashes when I run it on my 4.1 Final Edition or beta installations, but works fine under 4.1 Update 6.

The crash AFAICT is because of a NULL elf handle being passed to IElf->CloseElf() from:
hieronymus:Bosch_StopAcquisition()+0x3fc (section 1 @ 0xBA8)

@kas1e

Have you tried disabling the three lines before alutExit?



These should be unnecessary and may cause problems as alutExit() does more or less the same when called later in the program.