bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Segmentation fault with Emacs mode


From: Juergen Sauermann
Subject: Re: [Bug-apl] Segmentation fault with Emacs mode
Date: Sun, 04 May 2014 11:46:50 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi Blake,

before the fix, )LOAD would )CLEAR first, which deletes all functions including native ones,
which dlclose()s the shared library providing the native function, which invalidates all callbacks
installed b the shared library.

After the fix, the shared library is not dlclosed() automatically but left open.

The dlopen()/dlclose() themselves make sure that the same library is not loaded twice. So dlclose()
merely saves a few bytes in memory but (as we have seen) can cause problems as well. The only case
where dlclose() is really needed is when you want load a different version of the same library.

So the fix should work for all libraries not only for emacs mode, and
the other libraries are not affected except that their library is no longer dlclosed().
If a shared library wants to be really clean then it can provide a function called "close_fun".
This function will be called if present, and if it returns true then the library will be dlclosed().

See FILE_IO or the templates in the 'native' subdir how to use close_fun().

/// Jürgen



On 05/04/2014 01:19 AM, Blake McBride wrote:
Greetings,

I updated GNU APL & Emacs mode and it does appear to work now.  Thanks a lot!  I think I understand the issue but it leads me to the following question.  When loading other libraries (such as sqlite, component file system, etc.) the same issue would arise.  What happens if you open the shared library and then do a )load?  Although a )load should wipe out any APL functions, I wouldn't expect it to unload shared libraries.  I would think shared libraries would represent something at a higher level than a workspace.  It sounds like you fixed this for Emacs mode.  Two questions:

Does this fix the problem for the other shared libraries I mentioned?

Is there something those shared library authors need to change?

Thanks!!

Blake



On Sat, May 3, 2014 at 12:33 PM, Juergen Sauermann <address@hidden> wrote:
Hi,

changed in SVN 243. I also added the caller argument in close_fun() and in the eval_XXX() functions.
Maybe you want to update back.

/// Jürgen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]