Opened 5 years ago

Last modified 5 years ago

#1183 reopened defect

CFFI, Mac OS X, shared libraries, crash

Reported by: veritas Owned by:
Priority: critical Milestone:
Component: Foreign Function Interface Version: trunk
Keywords: cffi, run-program Cc:

Description

Thanks for previous bug fix with close-shared-library.

Attached application do:

  1. compile C program as shared library
  2. open library at CL
  3. call foreign function
  4. close library

Now it works, but only once. On next iteration (run-program "gcc"...) crashes with sigsegv signal. Strange, but I can run gcc manually, and 2-4 works.

Attachments (1)

pub.lisp (817 bytes) - added by veritas 5 years ago.

Download all attachments as: .zip

Change History (3)

Changed 5 years ago by veritas

comment:1 Changed 5 years ago by gb

  • Resolution set to fixed
  • Status changed from new to closed

This should be fixed in the trunk in r16076

comment:2 Changed 5 years ago by veritas

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry, maybe I can't recompile trunk kernel properly, but I got such error (at second call of slowly-get-number):

> Error: Shared library not open: "/private/tmp/shared/libmain.dylib"
> While executing: CCL::ENSURE-OPEN-SHLIB, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

I tried to replace ccl::ensure-open-shlib with

 (defun ensure-open-shlib (c force)
  (if (stream-open-p *standard-output*
    (describe c))
  *rtld-use*) 

getting

#<SHLIB /private/tmp/shared/libmain.dylib #x302000E54DED>
Type: SHLIB
Class: #<BUILT-IN-CLASS SHLIB>
TYPE: (SHLIB . #<CCL::CLASS-WRAPPER SHLIB #x3000400276ED>)
SHLIB.SONAME: "/private/tmp/shared/libmain.dylib"
SHLIB.PATHNAME: NIL
SHLIB.HANDLE: NIL
SHLIB.MAP: NIL
SHLIB.BASE: NIL
SHLIB.OPENCOUNT: 0

and it works (with ugly hack, of course).

What's the problem with ensure-open-shlib? Why handle and map are nil at function call time?

Note: See TracTickets for help on using tickets.