After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 363501 - script-fu.exe stays running if gimp crashes or is killed
script-fu.exe stays running if gimp crashes or is killed
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.2.x
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 465929 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-19 20:57 UTC by nuncus
Modified: 2008-01-15 13:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description nuncus 2006-10-19 20:57:37 UTC
O/S = Win XP; Home Ed.; Sevc Pk 2.
GTK = 2.9.9  (gtk+-2.8.9-setup-1.zip)
GIMP = 2.2.13
-------------------------------------

PROBLEM:  Scriptfu.exe does not always unload, and usually does not, upon exiting GIMP.  When GIMP is launched again, scriptfu.exe instantiates another copy of itself into memory; this copy of scriptfu.exe also usually fails to unload upon exiting GIMP.  The result is ultimately a crash of GIMP.

HOW TO REPRODUCE:  I am unable to provide any step by step process to replicate this apparent bug and its behavior other than to say this:  use GIMP for a while; unload GIMP; check Task Manager to see if scriptfu.exe unloaed from memory when GIMP unloaded; do NOT "end process" for scriptfu.exe.  Re-launch GIMP and use a scriptfu script, or multiple scripts; see, in Task Manager, if a second instance of scriptfu was instantiated in memory; if so, exit GIMP and check again to determine whether and to what extent one or both instantiations in memory of scriptfu unloaded when you exited GIMP.  In other words, just let the instantiations of scriptfu build up on your machine, if in fact scriptfu is behaving in this untoward manner on your machine.

I have found as many as 5 or 7 scriptfu.exe programs loaded into memory -- cumulatively -- at one time.

Ultimately, the accumulated scriptfu.exe programs in memory will crash GIMP.

I have noted that ONLY ONE among the accumulated scriptfu.exe instantiations in memory is actually being used in the current session by GIMP.  I base this conclusion on the fact that, when I do in fact start to unnload the multiple instances of scriptfu.exe from memory in Windows's Task Manager by "End Process," only ONE such scriptfu.exe process termination throws the GIMP dialog box advising me that the terminated process "messed up" GIMP upon termination of the scriptfu.exe process and that I probably should exit GIMP (if GIMP is then running, of course) and restart the app from scratch.

To date, these GIMP crashes have yet to actually crash Windows XP; but, as the scriptfu.exe instantiations increase in number, the various Windows apps do begin to slow down and behave a bit erratically -- presumably from the decreasing RAM available to them.

Finally, this occurred in my previous version of GIMP also, which was 2.2.12.  My O/S at that time was identical in all respects to the O/S being used at the time this bug report has been filed.

In closing, I was unclear as to whether this should be reported under GTK or GIMP.  Since I am not a computer programmer or software engineer, GTK is in the category of "magic" to me and a bit esoteric for me to be offering any kind of bug report; if this is a GTK problem and not a GIMP problem, presumably one of the developers will move this bug report to the proper location in Bugzilla.

In very general, layman's terms, it seems to me that either the Windows O/S is not being properly notified that it should unload scriptfu.exe from memory upon exiting from GIMP, or, if it is GIMP's responsibility for unloading its command interpreter upon exit, GIMP is failing to do as it should.

I hope this helps,

JNuncus
Comment 1 Sven Neumann 2006-10-20 08:50:01 UTC
The script-fu process is launched by the gimp process. It's the operating system's job to close it when the parent process exits. Or, in other words, your operating system sucks and you should ask those people in Redmond to fix it.
Comment 2 nuncus 2006-10-20 19:38:10 UTC
(In reply to comment #1)
> The script-fu process is launched by the gimp process. It's the operating
> system's job to close it when the parent process exits. Or, in other words,
> your operating system sucks and you should ask those people in Redmond to fix
> it.
> 

Well, by definition, the O/S is inferior -- has been,... getting on, what?  Twenty-six years now?  I keep hoping it's all a bad dream and that, when I wake up, it will have morphed into Linux.  One would think that, by now, however, it would at least be able to close a program that has been exited.  Believe me, if I weren't dependent on a couple of other programs. aside from GIMP, that require Windows, it would have been history sometime circa 1996.  :-)
Comment 3 Tor Lillqvist 2006-11-24 02:55:47 UTC
In normal cases script-fu does exit when one quits GIMP. What do you mean with "unload GIMP"? Killing it from Task Manager? In that case (or if GIMP crashes) the script-fu.exe process indeed stays behind, and that I guess is a bug.

But killing gimp this is hardly the normal way to quit GIMP. If you quit it normally, either by closing the toolbox window, or through the menu, script-fu.exe does exit, too.
Comment 4 Tor Lillqvist 2007-01-25 11:41:53 UTC
Fixing this is trivial if one can use SetHandleInformation() which is present only in NT-based Windows (i.e. not Win9x/Me). So I guess if we still want to support Win9x in GIMP 2.2, this can be fixed only in trunk. Committed:

2007-01-25  Tor Lillqvist  <tml@novell.com>

	* app/plug-in/gimpplugin.c (gimp_plug_in_open): On Win32 prevent
	plug-in from inheriting GIMP's ends of the pipes. Fixes #363501.

For 2.2 a more complex solution would be necessary: Pass also information what fds are gimp's ends of the pipes to the plug-in, and have it explicitly close them when it starts.
Comment 5 Sven Neumann 2007-08-12 12:10:48 UTC
*** Bug 465929 has been marked as a duplicate of this bug. ***