Ticket #63 (closed defect: invalid)

Opened 3 years ago

Last modified 4 months ago

ThreadExecutor interruption tests fail sporadically

Reported by: kaiw Assigned to:
Priority: moderate Keywords:
Cc:

Description

On my machine (a standard up-to-date install of Fedora 10) the ThreadExecutor? tests fail approximately 4 times out of 10 with: 

Traceback (most recent call last):
  File "lib/reinteract/thread_executor.py", line 315, in <module>
    ("z = 1", Statement.COMPILE_SUCCESS, None)
  File "lib/reinteract/thread_executor.py", line 283, in test_execute
    raise AssertionError("Interrupting ThreadExecutor failed")
AssertionError: Interrupting ThreadExecutor failed

Occasionally the following line is appended: 

User defined signal 1

If the tests pass, they pass within just over one second. When the tests fail, they take different lengths of time to fail, typically between 2 and 8 seconds.

Change History

(follow-up: ↓ 2 ) 12/28/08 10:18:52 changed by otaylor

I'm quite mystified by this ... the test is absolutely reliable on this Fedora 10 system. I guess it's some sort of timing issue. This is a Pentium M 1.7GHz. When I get back after the holidays I'll do some tests on my other system, which is a faster dual-core x86_64 machine. Would you characterize your machine as especially fast or slow?

From reading the back trace, it looks like the failure is occurring in the 'for x in xrange(0,100000000):' test, which is even more surprising to me, since I would expect that to be quite reliable and the syscall test to be potentially less reliable.

(I don't see any reason for unreliability when rereading the relevant bits of the Python codebase.)

(in reply to: ↑ 1 ) 12/28/08 11:39:33 changed by kaiw

Replying to otaylor:

I'm quite mystified by this ... the test is absolutely reliable on this Fedora 10 system.

As it turns out, I had pygtk2 from updates-testing installed, but downgrading made no difference.

I guess it's some sort of timing issue. This is a Pentium M 1.7GHz. When I get back after the holidays I'll do some tests on my other system, which is a faster dual-core x86_64 machine. Would you characterize your machine as especially fast or slow?

It's a first-gen Macbook (dual-core 32 bit intel 1.83GHz) so not particularly slow, but not speedy by today's standards

From reading the back trace, it looks like the failure is occurring in the 'for x in xrange(0,100000000):' test, which is even more surprising to me, since I would expect that to be quite reliable and the syscall test to be potentially less reliable.

Commenting out the xrange test, the syscall test passes very reliably for me, without a single interruption failure. I did once get it to fail with: 

Traceback (most recent call last):
  File "lib/reinteract/thread_executor.py", line 326, in <module>
    ("z = 1", Statement.COMPILE_SUCCESS, None)
  File "lib/reinteract/thread_executor.py", line 288, in test_execute
    assert_equals(s._got_state, s._expected_state)
  File "/home/kaiw/Hacking/reinteract/reinteract/lib/reinteract/test_utils.py", line 11, in assert_equals
    raise AssertionError("Got %r, expected %r" % (result, expected))
AssertionError: Got 4, expected 6

but that looks like a completely different problem.

03/27/09 20:47:45 changed by lamby

If it helps, I am reliably seeing (what appears to be) the same failure with the xrange(0,100000000) test. I am running Debian's Python 2.5.4 on a Q6600 quad-core machine.

The test actually fails with the pthread_kill call causing the process to segfault. However, a quick glance of the code suggests you are guarding this call in the usual way, so I'm not sure what's going on.

I can also reproduce the problem inside the normal workbook by running some long xrange and trying to interrupt it; naturally, the SIGSEGV takes out the entire program.

09/27/11 23:33:54 changed by otaylor

Moved to https://bugzilla.gnome.org/show_bug.cgi?id=660319, resolving as "invalid"

09/27/11 23:53:09 changed by otaylor

  • status changed from new to closed.
  • resolution set to invalid.