Bug#555540: any news on tokyocabinet's FTBFS?

[Bastian Blank]

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(!)

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

[Serafeim Zanikolas]

Post by Bastian Blank

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(!)

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.

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

[Pierre Habouzit]

Post by Bastian Blank

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(!)

Does tokyocabinet use multi-threading or some other means of
concurrency?

Yes it does heavily in the test-suite.

Post by Bastian Blank
For me this looks like race conditions.

I agree with this.

Post by Bastian Blank
They may live in the glibc, as there were some fixes in this area
lately.

The fact that no other architecture has ever shown the same failures
indeed points towards multithreading issues on 390 in the kernel or
glibc.
--
·O· Pierre Habouzit
··O ***@debian.org
OOO http://www.madism.org

[Pierre Habouzit]

reassign 555540 libc6
retitle 555540 [s390] synchronization/locking issues
severity 555540 important
thanks

Post by Bastian Blank

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(!)

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

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.
--
·O· Pierre Habouzit
··O ***@debian.org
OOO http://www.madism.org