Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#4180 load of shared objects leaves temporary files on windows

obsolete: 8.5.5
closed-fixed
Jan Nijtmans
9
2008-11-14
2008-11-12
No

On Windows loading shared objects from a virtual file system,
e.g. starkits, leaves temporary files behind after interpreter exits.

Discussion

  • The following patch fixes the bug:

    --- generic/tclLoad.c 7 Oct 2008 20:51:46 -0000 1.16.4.1
    +++ generic/tclLoad.c 12 Nov 2008 13:21:09 -0000
    @@ -1154,7 +1154,7 @@

    if (pkgPtr->fileName[0] != '\0') {
    Tcl_FSUnloadFileProc *unLoadProcPtr = pkgPtr->unLoadProcPtr;
    - if ((unLoadProcPtr != NULL) && (pkgPtr->unloadProc != NULL)) {
    + if (unLoadProcPtr != NULL) {
    (*unLoadProcPtr)(pkgPtr->loadHandle);
    }
    }

     
  • Don Porter
    Don Porter
    2008-11-12

    • priority: 5 --> 9
    • assigned_to: kennykb --> nijtmans
     
  • Don Porter
    Don Porter
    2008-11-12

    There's a battle here with
    Bug 2059262.

     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-12

    The problem here is: how can we know that the dll
    which is unloaded here doesn't install an exit handler?
    If it does, it will lead to a crash as soon as the
    application exists. So, what is worse, a file leak
    or a crash? The only idea I have now is that in stead
    of unloading at this point, Tcl could install an
    exit handler which does the unloading at a later
    time. However, is the unLoadProc then still
    available? Ideas welcome.

    (Does this really have prio 9?)

     
  • I'm just starting to discover how intricated the finalization hairball is, but I suspect that delaying things is not the solution; indeed, in bug 2270477 we've just seen what happens when an exit handler schedules things for "later"...

    Now unLoadProc and exitHandler seem a bit in contradiction... I understand that unloading is a rather recent feature, so there are extensions without an unLoadProc, but for those who have both, we could decide than the unLoadProc takes over and automatically de-registers the exitHandler ? Or calls it immediately ?

     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-13

    > I'm just starting to discover how intricated the finalization hairball is,
    > but I suspect that delaying things is not the solution; indeed, in bug

    Indeed, thinking more about it, delaying is not the solution: On Windows
    and HP-UX it is impossible to remove a shared library from the filesystem
    when it is not unloaded.

    But I have a better idea now. If the dll is loaded from a
    VFS file system, then its unloadProc is FSUnloadTempFile
    (a static function in tclIOUtil.c). So we can simply
    check for this, and allowing the unload in this
    situation. That's a much simpler fix, and it prevents
    muggling with exit handler related things!

    > an unLoadProc, but for those who have both, we could decide than the
    > unLoadProc takes over and automatically de-registers the exitHandler ? Or
    > calls it immediately ?
    Yes, this is how it should be. But the problematic libraries
    referred to in [Bug 2059262] don't have any way to de-register
    or run the exitHandler (believe me, I searched for that before
    filing 2059262!).

    Regards,
    Jan Nijtmans

     
  • > But the problematic libraries
    > referred to in [Bug 2059262] don't have
    > any way to de-register
    > or run the exitHandler

    The idea was not for the library itself to do it, but for the generic Tcl code... Maybe it doesn't make sense, I don't know the details :-} Tell me.

     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-13

    Checked in the fix, in tclLoad.c 1.21. It just restores the
    behaviour from before Bugfix 2059262 when the library comes
    from VFS. If the librarie doesn't come from VFS, nothing
    changes. It's the most simple solution I can think of.
    The only dis-advantage is that when the library has no
    unloadProc, the real unloading from memory is left to
    the OS. If you don't want this, there is an easy workaround:
    Just give the library an unLoadProc, even an empty one suffices.

    This means that ill-behaved libraries still cannot be loaded
    from VFS: it will lead to a core-dump when the application
    ends. Lucky enough, I cannot imagine that anyone would like
    to load Oracle from a starkit: It simply is too dependant on
    other files installed to be useful. I can live with that
    limitation.

    If anyone has a better suggestion, I'm all ears!

    Still needs to be backported, so leaving open.

     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-14

    Backported to core-8-5-branch, so can be closed.

    If someone has a better idea, feel free to re-open
    this artifact with (lots of) comments!

    Regards,
    Jan Nijtmans

     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-14

    • status: open --> closed-fixed
     
  • Jan Nijtmans
    Jan Nijtmans
    2008-11-14

    Created lower-priority follow-up:
    [ 2282547 ] load of ill-behaved shared library from VFS: core dump