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:
- diff.txt [download] added by nijtmans on 2008-08-19 15:23:53. [details]