Bugs item #1229218, was opened at 2005-06-28 14:21
Message generated for change (Settings changed) made by warnes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=453021&aid=1229218&group_id=48422
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: rpy
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Barry Rountree (rountree)
Assigned to: Gregory Warnes (warnes)
Summary: race condition on exit
Initial Comment:
The following happens more often than not. I've seen
it on a recent sid build and verified it with my own
compile of python+R+rpy. It only happens on exit and
no other R functionality is affected.
-----
Exception in thread Thread-1 (most likely raised during
interpreter shutdown):
Traceback (most recent call last):
File
"/home/rountree3/install/lib/python2.4/threading.py",
line 442, in __bootstrap
File
"/home/rountree3/install/lib/python2.4/threading.py",
line 422, in run
File "/home/rountree3/install/lib/python/rpy.py",
line 116, in r_eventloop
exceptions.AttributeError: 'NoneType' object has no
attribute 'isSet'
Unhandled exception in thread started by
Error in sys.excepthook:
Original exception was:
-----
R 2.1.1 (2005-06-20).
Python 2.4.1
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
rpy_version = "0.4.2.1"
I'm happy to help test or debug.
Thanks, and keep up the great work!
Barry
rountree at cs . uga . edu
----------------------------------------------------------------------
Comment By: Phil Groce (pgroce)
Date: 2005-09-01 08:48
Message:
Logged In: YES
user_id=213365
Oh, yeah, stop_r_eventloop, not r_stop_eventloop. I came
back to this bug to use as a reference and kept getting
errors -- darned open source support. :)
Sorry I haven't gotten back to you on your request for a
unit test -- I can't reliably reproduce the problem to the
point that I could say a unit test definitively passes or
fails, unfortunately. The timing of the race condition is
something like:
1. Python decides to shutdown and signals this to threads.
2. The R thread starts to shut down
3. Python deletes structures the R thread would really like
to keep around until it shuts down.
4. The R thread gets to the point that it wants those structures
5. SIGSEGV
If #2 happens fast enough, 4 happens before 3 and everything
works fine. So you'd need to slow down the R thread enough
to trigger the race condition. (In practice, the culprit
seems to be IO to the disk, which is obviously difficult to
control.)
FWIW, I independently rediscovered this problem. :) (I was
using rpy in a module, and not running stop_r_eventloop() in
my top-level code.) Adding the stop_r_eventloop() call fixed
things right up. I don't know if that makes you feel good
about closing the bug, but it's a data point, at least.
What do you think about making this a FAQ? Like the original
bug reporter said, thanks for all the great work on this. :)
----------------------------------------------------------------------
Comment By: Gregory Warnes (warnes)
Date: 2005-07-27 13:57
Message:
Logged In: YES
user_id=9316
I've made the addition of
_r_thread.join()
to stop_r_eventloop().
Could you provide an example that shows the problem so that
I can create a test case?
Thanks,
-Greg
----------------------------------------------------------------------
Comment By: Phil Groce (pgroce)
Date: 2005-07-27 11:05
Message:
Logged In: YES
user_id=213365
I'm experiencing this on Debian Unstable with rpy 4.3.1.
What appears to be happening is that the python main process
cleanup is happening before the event loop thread is torn
down, and removing things r_eventloop expects to be in the
global namespace. If I wrap my main code in a try/finally
thusly, I don't get the error:
if __name__ == "__main__":
try:
main()
finally:
r_stop_eventloop()
I suspect this is not sufficient, and that r_stop_eventloop
should join() _r_thread before it returns:
def stop_r_eventloop():
_r_events_running.clear()
_r_thread.join()
I added this line to rpy.py and re-ran the above test and it
continued to work, so the join() appears harmless, at least.
I didn't do anything tricky with it, however.
----------------------------------------------------------------------
Comment By: Gregory Warnes (warnes)
Date: 2005-07-14 15:18
Message:
Logged In: YES
user_id=9316
This might be fixed in 0.4.3. Please check.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=453021&aid=1229218&group_id=48422
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
