Tcl Source Code

View Ticket
Login
Ticket UUID: 2059262
Title: regression: crash after unloading proprietary library
Type: Bug Version: obsolete: 8.5.4
Submitter: nijtmans Created on: 2008-08-19 08:23:53
Subsystem: 40. Dynamic Loading Assigned To: nijtmans
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2008-11-14 16:12:20
Resolution: Fixed Closed By: nijtmans
    Closed on: 2008-10-07 23:18:04
Description:
Some libraries, e.g. the Mbx library from the secs project, let Tcl crash when the library is unloaded.
This is related to tip #239.
There has been a private discusson about that,
here are just some copies of the relevant parts:

=================================================

The reason we need the Tcl-level extras is that it introduces at least one key feature - per-library opt-out of being closed/unloaded.  This is very important for some libraries that have atexit handlers and similar weird issues (like Oracle's stuff).

Jeff

==================================================

Yes, I encountered a proprierary library as well
which has problems with unloading in Tcl 8.5
but worked perfectly in Tcl 8.4 ;-(. Shouln't
libraries report by itself if they support
unloading or not, in stead of building it in
in the load command? We could simply check
if the library has an unloadproc, and only
unload it if it has one. Something like the
patch below. Then any library which wants
the unload feature only has to define the 
symbol, that's it.

This patch seems to fix my problem (but
it is barely tested, so your comments are
welcome....)

Regards,
          Jan Nijtmans
==================================================
The problem with that is that it then adds the burden of creating the unload proc for all the well-behaved libraries.  It might be worth considering special values like Tcl_EventuallyFree does, whereby TCL_UNLOAD_OK could be specific as the unloadProc (meaning it should unload with the usual native stuff).

Any way you cut it, that just adds some special casing for something I want to be generalized.  If it means we need Tcl_Load* APIs, I think that's acceptable.

Jeff
==================================================
Thinking more about it, I think we are dealing
with two different things here:
1) A regression in Tcl 8.5 compared to 8.4. The
   mbx package I wrote for the secs project uses
   a proprietary library libCw.a. This library
   crashes when Tcl 8.5 exits, but with Tcl 8.4
   it works perfectly.
2) Extend the API in both Tcl and C to allow
   more control over the unloading of libraries.

Both should be considered separately. I propose
to submit a bug ticket for 1), which can be
solved without a TIP, and backported to Tcl
8.4. This private discussion can then be
continued there. It is indeed a burden to
create an unload proc for well-behaved
libraries, but that's small and easy and
it restores the Tcl 8.4 behaviour for
ill-behaved libraries. We only have to
do that for a small number of libraries
(the ones in the core), and only
the extension writers who want to support
unloading need to do it as well.
I volunteer to do that, as soon as we
reach agreement.

A separate issue is 2), which needs a TIP
and cannot be backported to Tcl 8.5. Personally,
for the C api I would just use dlopen, so we
don't have to do anything for Linux and friends.
But I can live very well with the proposed
Tcl_Load* API as well.

Regards,
        Jan Nijtmans
User Comments: nijtmans added on 2008-11-14 16:12:20:
This fix introduced an new bug:
  [ 2269431 ] load of shared objects leaves temporary files on windows

This bug is fixed now, but it leaves one remaining minor issue. Therefore,
a follow-up artifact is created:
  [ 2282547 ] load of ill-behaved shared library from VFS: core dump

nijtmans added on 2008-10-08 06:17:29:
Backported (tclLoad 1.16.4.1) for Tcl 8.5.5, so now can be closed

nijtmans added on 2008-10-07 22:56:38:
OK, I'll do it tonight

dgp added on 2008-10-07 21:29:21:
Normally I try to do an 8.5 patch
release about the same time as an
8.6 alpha release.  Which means I'm
aiming to get 8.5.5 out Real Soon Now.

nijtmans added on 2008-10-07 15:20:25:
There is only one minor reason to withold the backport:
It gives some time to Jeff and others to see if it fixes
the same problem with the Oracle library as well, before
it is put in a public Tcl8.5.5 release. (I checked that
the libCw problem is fixed by this, and yes it is).

I plan to do this well before Tcl8.5.5. The advantage of
it being in Tcl8.6a3 is that any feedback (however unlikely)
can still be handled before it occurs in a public release.

But if you prefer the backport now, I'll be glad to do it.

dgp added on 2008-10-07 01:02:05:
I don't follow the bug or the fix,
but is there any reason to withold
the backport?

nijtmans added on 2008-10-04 19:55:19:
fixed in generic/tclLoad 1.18. To be backported, therefore leave open

nijtmans added on 2008-08-25 17:41:58:
Logged In: YES 
user_id=61031
Originator: YES

Answer to previous question:

The problem is not the "unload" command. The problem arises when the application ends.
Then Tcl will call dlunload/shl_unload (or whatever the platform calls it) for
the library. The crash occurs when the application is terminated through "exit",
after everything else is cleaned up.

dkf added on 2008-08-25 17:35:09:
Logged In: YES 
user_id=79902
Originator: NO

A library is only unloadable if it has a *_Unload function exported; if the function is absent, [unload] will refuse to do anything with it at all. Why is such a function being exported in this case?

nijtmans added on 2008-08-19 15:23:53:

File Added - 289319: diff.txt

Attachments: