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 171453 - GIMP prints out alarming message when it loads a bitmap with a negative width (the bitmap is invalid)
GIMP prints out alarming message when it loads a bitmap with a negative width...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.2.x
Other All
: Normal trivial
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-03-24 05:54 UTC by David Costanzo
Modified: 2008-01-15 12:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The bitmap that was mentioned in the repro scenario (9.44 KB, image/bmp)
2005-03-24 16:13 UTC, David Costanzo
Details

Description David Costanzo 2005-03-24 05:54:25 UTC
Please describe the problem:
The GIMP prints out some alarming messages when it is asked to load a bitmap
that specifies a negative width (the bitmap is corrupt).  As far as I can tell,
there are no negative effects (for example, the GIMP does not crash).  Still,
this feels like something that you might want to know about.

Here's what GIMP prints out:

(bmp:16758): LibGimp-CRITICAL **: file gimpdrawable.c: line 63
(gimp_drawable_get): assertion `width > 0 && height > 0 && bpp > 0' failed
/usr/local/lib/gimp/2.0/plug-ins/bmp: fatal error: Segmentation fault


Steps to reproduce:
1. Run GIMP from the command line
2. Load width-negative.bmp


Actual results:
The GIMP prints out the assert failure and the segmentation fault on the command
line.  It also pops up an "OK" dialog box saying that the bitmap could not be
opened.

Expected results:
Gimp pops up an "OK" dialog box saying that the bitmap could not be opened
(there are no printouts on the command line).

Does this happen every time?
Yes

Other information:
Comment 1 Sven Neumann 2005-03-24 13:23:46 UTC
Please attach the BMP image that triggers the problem to this bug report.
Comment 2 David Costanzo 2005-03-24 16:13:40 UTC
Created attachment 39202 [details]
The bitmap that was mentioned in the repro scenario
Comment 3 weskaggs 2005-03-24 17:10:57 UTC
removing NEEDINFO since info has been provided.
Comment 4 Sven Neumann 2005-03-24 17:18:27 UTC
I cannot reproduce this problem with the CVS version of GIMP. The plug-in
correctly refuses to read the BMP saying: "'foo.bmp' is not a valid BMP file".
Someone should test this with GIMP 2.2...
Comment 5 weskaggs 2005-03-24 19:03:24 UTC
It does indeed fail in the 2.2 version of bmp.  The difference is the error
checking that Sven added in revision 1.38 of bmpread.c.
Comment 6 Sven Neumann 2005-03-24 20:22:38 UTC
I didn't add any extra error checking, the changes from 1.37 to 1.38 are the
port to g_stdio and some formatting changes.

What about the fix for bug #158033? Could that be related? Anyway, I think the
best we can do is to carefully backport all changes in bmpread.c to the 2.2
branch. This will also close bug #171306.
Comment 7 Sven Neumann 2005-03-24 20:40:39 UTC
Hmm, trying to load the same BMP at home using the bmp plug-in from CVS and it
fails with the reported warnings. No idea why the plug-in refused the file at
work. Perhaps I did something wrong when downloading the file. Sorry for the
confusion I have caused.
Comment 8 Sven Neumann 2005-03-24 20:57:47 UTC
Fixed in both branches:

2005-03-24  Sven Neumann  <sven@gimp.org>

	* plug-ins/bmp/bmp.h (Bitmap_Head_Struct)
	* plug-ins/bmp/bmpread.c: use a signed long for width and height
	and check that width is > 0 (negative height is allowed and
	handled by our code). Fixes bug #171453.