load-shared-library from non-main thread causes trace/BPT trap

Bug #592425 reported by Cyrus Harmon on 2010-06-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

calling (load-shared-object ...) from threads other than the main thread cause a trace/BPT trap. Apparently this used to be fine, but 10.6 supposedly changed the behavior here. Also, the root of the problem may be the CFInitialize might need to be called on the main thread and then things _might_ be ok.

Possible solutions include:

1. leaving this as is and making it the user's responsibility to make sure he or she is on the main thread when calling load-shared-library, but this is a pain for slime sessions

2. make (load-shared-object ...) interrupt the main thread and call dlopen from there

3. call CFInitialize from the main thread during the normal initialization sequence

Suggestions? Requests?

Darwin Beaune.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386


Cyrus Harmon (ch-launchpad) wrote :

Linking against -framework CoreFoundation seems to help. I'm reluctant to declare this fixed until I have a fuller understanding of what the problem really is, however.

Changed in sbcl:
importance: Undecided → Medium
status: New → Triaged
tags: added: os-darwin
Hans Hübner (hans-huebner) wrote :

I'm seeing this happen consistently with SBCL on Mac OS X 10.8.2 - The suggestions above work for the moment, but it is an inconvenient thing to have to remember.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers