#555540 [s390] synchronization/locking issues

Package:
libc6
Source:
glibc
Description:
GNU C Library: Shared libraries
Submitter:
Bastian Blank
Date:
2010-05-19 21:57:13 UTC
Severity:
important
#555540#5
Date:
2009-11-10 09:06:40 UTC
From:
To:
There was an error while trying to autobuild your package:
[...]
#555540#14
Date:
2010-02-07 19:29:19 UTC
From:
To:
Hi Pierre,
is this fixed? if it is then the bug should be closed, otherwise, I suppose, the
package in testing won't be upgraded.

We, as mutt maintainers, would like to switch from gdbm to tokyocabinet but we
need a stable and up-to-date version in testing to do so :-)

Cheers
Antonio
#555540#19
Date:
2010-02-08 14:36:22 UTC
From:
To:
I don't know, it's reassigned to linux-2.6. Since it's a linux bug, I've
disabled the testsuite on armel for the time being.

Well, it remains an issue on hppa sadly :/
#555540#24
Date:
2010-05-11 20:52:09 UTC
From:
To:
Hi Pierre,

Here's a ping for #555540, which is blocking the transition of bogofilter (for
quite a while now). It'd be sad to have to drop bogofilter support for
tokyocabinet.

Cheers,
Serafeim
#555540#29
Date:
2010-05-14 19:43:27 UTC
From:
To:
This ftbfs is random and only on s390, you're welcome to track it down,
I've not been able to.
#555540#34
Date:
2010-05-18 00:47:58 UTC
From:
To:
It seems that on consecutive runs of the test case[1] in question, it aborts
at different points each time and even succeeds in one in five runs or so.
Moreover, while the combined assert() condition fails, separate assert() calls
for each of the condition succeed while their combination still fail(!)

All in all, the whole thing sounds like a miscompilation/toolchain bug. I
tried compiling (on zelenka, b-d installed there) with -O0 and indeed the
whole test suite succeeds.

BTW, compiling with -O0 was more tricky than just exporting DEB_BUILD_OPTS;
upstream's configure script is doing something fishy with its own CFLAGS
variable (called MYCFLAGS) with the goal of redefining optimization levels
depending on configure options; you should probably fix this.

Finally, while you mentioned that the bug is in linux-2.6, I couldn't find any
indication about that on this bug report, which is still assigned to
tokyocabinet. If there is another bug on Linux that's affecting this bug, I
couldn't find it; in any case, you should probably mark this on the BTS.

Regards,
Faidon

1: LD_LIBRARY_PATH=.  ./tcbmttest read -df 5 casket 5
#555540#39
Date:
2010-05-18 08:32:13 UTC
From:
To:
Does tokyocabinet use multi-threading or some other means of
concurrency? For me this looks like race conditions. They may live in
the glibc, as there were some fixes in this area lately.

Bastian
#555540#44
Date:
2010-05-18 21:10:15 UTC
From:
To:
Thanks guys! Indeed tokyocabinet does use multi-threading.

    $ find tokyocabinet-1.4.37/ -type f | xargs grep thread | wc -l
    730
    $ grep -c thread tokyocabinet-1.4.37/tcbmttest.c
    60

Bastian, I don't see any related recent entries in the glibc changelog. If the
fixes are still pending, is there a bug we could denote as a blocker for
#555540?

Cheers,
Serafeim
#555540#49
Date:
2010-05-19 12:33:20 UTC
From:
To:
This was a mixup with another bug affecting arm, which is now closed.
#555540#54
Date:
2010-05-19 12:34:39 UTC
From:
To:
Yes it does heavily in the test-suite.

I agree with this.

The fact that no other architecture has ever shown the same failures
indeed points towards multithreading issues on 390 in the kernel or
glibc.
#555540#59
Date:
2010-05-19 21:47:02 UTC
From:
To:
reassign 555540 libc6
retitle 555540 [s390] synchronization/locking issues
severity 555540 important
thanks

For now I've disabled pthread support on s390 and the testsuite passed
on zelenka just fine.

I'm reassigning this bug to the glibc as it is *very* likely to be a
synchronization issue, not unlike the missing memory constraints we had
2 years ago.