EINVAL in pthread_mutex*() and sem_*() APIs

32 views
Skip to first unread message

SK

unread,
Jan 20, 2021, 10:04:54 PM1/20/21
to emscripten-discuss
Hello,

I'm using Emscripten with "-s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1 -s PROXY_POSIX_SOCKETS=1 -pthread -g4" compile/ link options to compile two different object files which are then linked together in the end with same options.

However, I'm finding that in object 2, if I use pthread_mutex_* APIs the second call fails with EINVAL, also sem_*() APIs too fail with same EINVAL. However, if I allocate ,initialize and return a pointer to pthread_mutex_t variable after initialization in object 1, it works perfectly fine. Lock/ unlock also works fine with pointer passing from object 2 -> 1. But still, the later pthread_cond_wait() calls fail again with EINVAL.

Am I missing any compiler/ linker flags here? I can reproduce the issue in both Win 10 & Ubuntu 20.04 Chrome as well as Linux Firefox.

Thanks,
Sarang.

Sam Clegg

unread,
Jan 20, 2021, 11:33:42 PM1/20/21
to emscripte...@googlegroups.com
Can you perhaps attach the failing code?   We don't have any current know issues with pthread locks of semaphores that I know of.   Does the code in question work in non-emscripten environments?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/eafcaaf3-2745-41f2-a3b2-793a6e27ff89n%40googlegroups.com.

SK

unread,
Jan 31, 2021, 5:10:13 PM1/31/21
to emscripten-discuss
Turned out to be red herring, a dependent library was altering errno which was leading to incorrect code path.

Thanks,
Sarang.
Reply all
Reply to author
Forward
0 new messages