SB-CONCURRENCY-TEST::FRLOCK.1 fails

Bug #1087955 reported by madanyang
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Undecided
Douglas Katzman

Bug Description

Hi,

I am one of the maintainers of sbcl for opensuse packaging. When building the sbcl 1.1.2 for openSUSE in the build system for the distro sometimes the testin of sb-concurrency fails "Test SB-CONCURRENCY-TEST::FRLOCK.1 failed" .

I am building the package for various openSUSE releases and SLES , and this happens randomly, meaning in another build it will succeed but the next time it may fail again for x86 or x86_64 or both.
The builds are on KVM instances and for each build the kvm is reinitiliazed doing just that package build they are isolated with no services running.

Here is what I get back for two different openSUSE releases; the first one for i586 and the second for x86_64

 Doing 25 pending tests of 25 tests total.
 Test SB-CONCURRENCY-TEST::FRLOCK.1 failed
 Form: (HANDLER-CASE
        (WITH-TIMEOUT 60
          (SB-CONCURRENCY-TEST::TEST-FRLOCKS))
        (TIMEOUT (SB-CONCURRENCY-TEST::C) (ERROR "~A" SB-CONCURRENCY-TEST::C)))
 Expected values: NIL
                  NIL
 Actual value: #<SIMPLE-ERROR "~A" {BC915F9}>.

 Doing 25 pending tests of 25 tests total.
 Test SB-CONCURRENCY-TEST::FRLOCK.1 failed
 Form: (HANDLER-CASE
        (WITH-TIMEOUT 60
          (SB-CONCURRENCY-TEST::TEST-FRLOCKS))
        (TIMEOUT (SB-CONCURRENCY-TEST::C) (ERROR "~A" SB-CONCURRENCY-TEST::C)))
 Expected values: NIL
                  NIL
 Actual value: #<SIMPLE-ERROR "~A" {1004BA1BC3}>.

Thanks
Togan Muftuoglu

Stas Boukarev (stassats)
description: updated
Revision history for this message
madanyang (toganm-u) wrote :

As suggested on the irc (deftest* (...) (time (handler-case ...)) ...)

Revision history for this message
madanyang (toganm-u) wrote :

corrected timing function for the test

Revision history for this message
David Lichteblau (david-lichteblau) wrote :

Note that this is not the "idle hang" bug that the Windows port is affected by. Rather, there is much CPU activity going on, and possibly the timeout of 60s is just too low for the slow hardware in use.

So this might go away if we fixed the Windows bug and removed the with-timeout.

Or we could make the with-timeout #+win32.

Revision history for this message
Stas Boukarev (stassats) wrote :

This also happens on linux-ppc.

Changed in sbcl:
status: New → Confirmed
Revision history for this message
Samuel Edwin Ward (seward-u) wrote :

To make explicit what is obvious to me after figuring it out myself and re-reading the other comments:

The timeout of 60 seconds in the definition of frlock.1 contrib/sb-concurrency/tests/test-frlock.lisp is not long enough in some (Linux) environments.

If you increase the timeout enough, the test will pass.

I'm not sure what the best long-term solution is.

Revision history for this message
LE GARREC Vincent (legarrec-vincent) wrote :

I have this problem since months with Gentoo. Every time I need to apply the following patch : https://bugs.gentoo.org/show_bug.cgi?id=468482 . Even if that's not the best solution, why do not commit this patch the time this problem is solve in another way ?

Revision history for this message
Cyrus Harmon (ch-launchpad) wrote :

I'm getting this bug (or similar) when running inside Docker on Mac OS, with current SBCL source (1.3.16.110).

Revision history for this message
Emile van Raaij (evr) wrote :

Can confirm this test failing as well as well while building on SBCL 1.3.20 stable on a Ubuntu 16.04 VPS instance, with 4 Gb ram and 3 cores. It does NOT fail on Ubuntu 16.04 setup on my i7 dev machine.

SB-CONCURRENCY gets built fine and placed on ../obj/sbcl-home/contrib but the resulting 2 files are not copied over to /usr/local/lib/sbcl/contrib. Due to failing test I assume.

Once copied over I can (quicklisp-)load and run packages depending on it ok so far, (f.e. :woo).

Revision history for this message
Steve Wills (swills6) wrote :
Revision history for this message
Douglas Katzman (dougk) wrote :

would it possible to put the failing test in a file by itself, and run that until (or if) it fails _without_ the test runner?
I'd like to see the first occurrence of the actual error, not the vacuous "Actual value: #<SIMPLE-ERROR "~A" {1003A7B983}>." nor the "(ERROR "test-op failed with unexpected failures")" error.

Revision history for this message
Douglas Katzman (dougk) wrote :

the fix in bug 1636659 is correct, I'll apply that.

Douglas Katzman (dougk)
Changed in sbcl:
assignee: nobody → Douglas Katzman (dougk)
Revision history for this message
Douglas Katzman (dougk) wrote :
Changed in sbcl:
status: Confirmed → Fix Committed
Stas Boukarev (stassats)
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.