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
