GNOME Bugzilla – Bug 461545
File handle left open after script parsing error
Last modified: 2018-05-24 12:13:53 UTC
Please describe the problem: I was working on my first GIMP script last night (using WordPad), so it was not much surprise that I encountered a few problems.... After registering the script, GIMP displayed a parse error ("end of file while inside list") because I had not nested my parentheses properly. I carefully combed over my script (in WordPad) and ultimately located and addressed the problem, however when I tried to save the file Windows denied me access, saying "the file is in use by another application". Steps to reproduce: 0. Start GIMP. 1. Open any script for editing (I use Wordpad). 2. Add or remove a parentheses (to induce a parsing error). 3. Refresh all GIMP scripts - naturally, it should display an error that the script could not be parsed. 4. Return to the script, remove the bug and save the script file again. Actual results: On step #4, WordPad tells me the file is "in use by another application" (i.e. GIMP) and "cannot be accessed", and I am unable to save my changes or fix the parse error. Expected results: I should, of course, have been able to save my changes and refresh the scripts with the new version. Does this happen every time? Unfortunately, no. I was on some occasions able to save changes to my script file and properly refresh the scripts, but once the error occured, I had to shut down GIMP before I could save any further changes to my script, and then restart GIMP to see if those changes had any effect. Turns out my script had several parse errors (last night was quite the crash course in script-fu), and I ultimately must have rebooted GIMP a dozen times before all the parse errors were finally nailed and I could actually run the script file on my image (to discover, of course, that I had yet more script errors to debug). Other information:
Script-Fu has been mostly reimplemented for GIMP 2.4. Could you try a recent GIMP 2.3 development release and check if you can still reproduce this problem there?
According to lsof this is handled correctly in GIMP 2.3. Closing as OBSOLETE. Please reopen if you have reason to believe that GIMP 2.3 is still affected.
Created attachment 114535 [details] Simplified example of a script that generates this bug
GIMP 2.4 for the most part addresses this bug, but I've discovered at least one scenario where it still occurs, and is easily replicable. Previous attachment is an (overly simplified) example of the bug: an unmatched closing parentheses causes GIMP to issue a "Syntax error: Illegal token" message, and the file handle is left open -- GIMP must be shut down before the error can be corrected using an external editor.
The main problem here is that your operating system is a piece of crap not allowing several applications to use one file at the time. But we should try to fix this in Script-Fu nevertheless.
I think this is only a problem of wordpad, as I did never encounter this problem with emacs, vi, notepad++ or other - real - editors.
Preferences about operating systems aside, when a Windows app opens a file it is the application's responsibility to specify whether the file should remain accessible by other programs while the handle is open. And it doesn't take a code monkey to figure out why most programs don't like to share write access to files they have opened for input. At least GIMP still allows other aplications to READ files it has opened, some programs (here's to you, MS Word) are known for completely locking down a file while it is open and not releasing the handle until the corresponding window has been killed. I have also been using PSPad lately for code editing, it has the same issue (but a far more generic error message, "Error saving file" instead of "The file is in use by another application and cannot be accessed").
The open file handle can be verified on Linux with lsof.
A number of bug fixes to the Script-Fu backported from the official TinyScheme sources changed the load operation and the Eval cycle. I do not see the open file problem. If no one reports still seeing this issue I will close the report as OBSOLETE.
I have downloaded a fresh copy of GIMP 2.6.10 but can still generate this error virtually on command. A test script with an unmatched closing parentheses generated "unmatched parentheses: 2", but the file handle was properly released and I was able to fix the problem immediately via external editor. A test script with an unmatched opening parentheses (the original attached example, in fact!) generated "invalid token: 1" and the file handle was NOT released. Closing GIMP was required in order to save any changes to the script file.
EDIT - Looks like I got my wording backwards in the previous comment. Unmatched opening parenthesis results in "unmatched parentheses" and a released file handle. Unmatched closing parenthesis results in "illegal token" and a locked file handle.
I can reproduce the problem using the attached script in GIMP 2.6.7 (the most recent version for my Linux distro) but not in GIMP 2.7.2. The difference between the behaviour of the 2.6 and 2.7 versions of GIMP will help in tracking down the problem.
Closing, because this is fixed in 2.7, and we don't fix 2.6 bugs any longer.
I have recently encountered this problem - again - in the win32 build of GIMP 2.8.0-RC1 . I am attaching two testcases that are able to generate it on command. The first script error was "Error: script-fu-register: toggle default must be an integer value" (because I should have typed SF-OPTION instead of SF-TOGGLE). The second script error was "Error: eval: unbound variable: bar" (because I forgot a set of parentheses in my define statement). On a hunch, I tried disabling the scripts folder (specifically, the one containing my script files) in my GIMP preferences to see if that yielded an acceptable workaround, but this had no effect on the problem - still had to shut GIMP off entirely before I could fix the problems in my script.
Created attachment 212521 [details] Testcase #2 (mistyped SF-OPTION instead of SF-TOGGLE during script-fu-register) Testcase: Mistyped SF-OPTION instead of SF-TOGGLE during script-fu-register
Created attachment 212522 [details] Testcase #3 (forgot parentheses during define)
PS: The original testcase still applies too.
I am able to reproduce this in current git master.
Kevin, any news on this one?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/247.