Your message dated Wed, 8 Jan 2025 21:24:17 +0100 with message-id <[email protected]> and subject line Re: Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture has caused the Debian Bug report #906917, regarding sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 906917: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906917 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libc6 Version: 2.24-11+deb9-u3 Using sem_timedwait on i686 gives random results. In out proprietary software semaphore used by two processes and located in shared memory mapped with mmap. All works under amd64 architecture and under another some distibutions. But under Debian Stretch amd64 sem_timedwait always blocks for timeout and returns ETIMEOUT error. Meanwhile it acquires the lock decreasing semaphore value. I've tried to make test for this bug. Test reproduces bug only with ASAN enabled. Without ASAN enabled it always passes. I've attached test but without ASAN support to show that I don't miss anything. I can modify test to enable ASAN support but if somebody ask. I've discovered that symbols used by i686 are different from those from amd64. On amd64 symbols are: ~$ nm "${PROJ_PATH}/Docker/debian/9/amd64/test-bugs/test-bugs" | grep sem_ U sem_destroy@@GLIBC_2.2.5 U sem_getvalue@@GLIBC_2.2.5 U sem_init@@GLIBC_2.2.5 U sem_post@@GLIBC_2.2.5 U sem_timedwait@@GLIBC_2.2.5 00000000004019b0 t test_process_sem_timedwait 00000000004011c0 t test_process_sem_timedwait_nolock But under i686 symbols are different: ~$ nm "${PROJ_PATH}/Docker/debian/9/i386/test-bugs/test-bugs" | grep sem_ U sem_destroy@@GLIBC_2.1 U sem_getvalue@@GLIBC_2.1 U sem_init@@GLIBC_2.1 U sem_post@@GLIBC_2.1 U sem_timedwait@@GLIBC_2.2 08049f50 t test_process_sem_timedwait 08048ee0 t test_process_sem_timedwait_nolock As you can see symbols are different for i686. Version of sem_init, sem_wait, sem_post, sem_destroy and sem_getvalue is GLIBC_2.1, but version of sem_timedwait is GLIBC_2.2. Replacing sem_timedwait with sem_wait makes all work on i686 architecture. So sem_wait is ok, but sem_timedwait is not. Problem reproduced under Docker Debian Stretch i386 image and with hardware installation made with debootstrap. -- Андрей Николаевич, инженер-программист.
test-bugs.tar.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---Version: 2.34-1 On 2019-01-16 14:51, Florian Weimer wrote: > * Андрей Доценко: > > > The problem occurs only when using semaphores in a library that is not > > linked against pthread. > > Yes, that's expected. Sorry I didn't see this earlier—we have an > upstream bug about this: > > <https://sourceware.org/bugzilla/show_bug.cgi?id=23543> > > In general, underlinking produces broken binaries. > Started with glibc 2.34, the functions from the pthread library have been moved into the libc one. As a consequence underlinking for the sem_* functions is not possible anymore when linked against libc 2.34 and later. I am therefore closing this bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
--- End Message ---
