Your message dated Wed, 8 Jan 2025 21:24:17 +0100 with message-id <Z37e8RtmlmynVSC-@aurel32.net> 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 owner@bugs.debian.org immediately.) -- 906917: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906917 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture
- From: Андрей Доценко <cnconlinux@gmail.com>
- Date: Wed, 22 Aug 2018 13:02:43 +0300
- Message-id: <CAK4ZEfPWG=PNhYOSbt1h2KOKDpQ-sWnSeDAbdOyme5=1fHT6QQ@mail.gmail.com>
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.--Андрей Николаевич, инженер-программист.Attachment: test-bugs.tar.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
- To: Андрей Доценко <cnconlinux@gmail.com>
- Cc: 906917-done@bugs.debian.org
- Subject: Re: Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture
- From: Aurelien Jarno <aurelien@aurel32.net>
- Date: Wed, 8 Jan 2025 21:24:17 +0100
- Message-id: <Z37e8RtmlmynVSC-@aurel32.net>
- In-reply-to: <87pnswyam2.fsf@oldenburg2.str.redhat.com>
- References: <20181230193110.GA29762@aurel32.net> <CAK4ZEfPWG=PNhYOSbt1h2KOKDpQ-sWnSeDAbdOyme5=1fHT6QQ@mail.gmail.com> <CAK4ZEfPhJ9dN9ZoEOJjHNEj4qa6Bba53xXgaGdfe-KwfJQ0okw@mail.gmail.com> <20190111155413.GA3167@aurel32.net> <CAK4ZEfPWG=PNhYOSbt1h2KOKDpQ-sWnSeDAbdOyme5=1fHT6QQ@mail.gmail.com> <CAK4ZEfOJ2rh2U6-+PfaLsmKtj7=BaEofjW2s-7qxY7RdsWVmPA@mail.gmail.com> <CAK4ZEfPWG=PNhYOSbt1h2KOKDpQ-sWnSeDAbdOyme5=1fHT6QQ@mail.gmail.com> <87pnswyam2.fsf@oldenburg2.str.redhat.com>
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 aurelien@aurel32.net http://aurel32.net
--- End Message ---