GNOME Bugzilla – Bug 139571
JPEG plug-in dies when loading empty or invalid JPEG file
Last modified: 2004-12-22 21:47:04 UTC
When trying to load an empty JPEG file or a file that has no correct JPEG header, the plug-in exits immediately without calling gimp_quit(). As a result, the GIMP reports that the plug-in has crashed. To reproduce: create an empty file (e.g. "touch empty.jpg") and try to open it or create an incorrect file (e.g. "echo test > test.jpg") and try to open it. Result: (gimp:23730): Gimp-Plug-In-WARNING **: gimp: plug_in_flush(): error: Broken pipe GIMP: Plug-In crashed: "jpeg" (/prefix/lib/gimp/2.0/plug-ins/jpeg) The dying Plug-In may have messed up GIMP's internal state. You may want to save your images and restart GIMP to be on the safe side. The error occurs in step 3 of load_image(), when it calls the function jpeg_read_header() from libjpeg. If it cannot read the header, that function displays an error message on the console such as "Empty input file" or "Not a JPEG file: starts with 0x..." and then exits immediately instead of calling the function my_error_exit(), which would call longjmp and then exit cleanly.
Raphael, will you attach a patch? I mean, you debugged it all to the point where you need to insert a single function call, didn't you?
Would be interesting to test how many file plug-ins act correctly on empty files. I suspect there are quite a few that could be made more robust in that area.
I wish I could attach a patch. But as I wrote above, the problem seems to be in libjpeg. I debugged that far and then found that the exit was called from within jpeg_read_header() without calling the exit function that the plug-in had registered. I will check the libjpeg code and see if there is anything that can be done about that, but I am not very optimistic.
This problem does not seem to occur in 2.0: either of the above test cases produces an error dialog and an error message in the command terminal (Fedora Core 1), but no plug-in crash. Could there have been a recent change in the jpeg plug-in that broke it?
Yes, two changes since 2.0.0. See bug #138357 and bug #138776.
Okay. The problem is caused by the fix to bug #138357, which reversed the order of two lines in the my_error_mgr struct. (Presumably libjpeg makes some unfortunate assumption about the order of fields in my_error_mgr.)
Ugh, I see what it's doing. It's overloading the structure by tacking on the jmf_buf at the end of it. Sigh, we'll have to workaround #138357 in another fashion.
2004-04-09 Manish Singh <yosh@gimp.org> * plug-ins/common/jpeg.c: Uglier workaround for bug #138357, since the previous one did break error handling. Fixes bug #139571.