Bug#326971: imview: Loading image causes stack smash?
I could not reproduce this bug with the image at http://justinpryzby.com/astro/m27.0001.Dumbbell_Nebula.FIT This FITS file loads fine, but is shown as all zeros. Thus, the support for FITS is broken, but don't see any crashes, string corruption or such. Could you check if you can repeat the behaviour mentioned in the original bug report with the latest version of imview, 1.1.8-3? If there's a GPL compatible C or C++ library for reading FITS-files, please let me know, I might add support for them at some point. Thanks, Teemu
Bug#326971: imview: Loading image causes stack smash?
On Wed, Jan 11, 2006 at 11:55:28PM +0200, Teemu Ikonen wrote:
I could not reproduce this bug with the image at
http://justinpryzby.com/astro/m27.0001.Dumbbell_Nebula.FIT
This FITS file loads fine, but is shown as all zeros. Thus, the
support for FITS is broken, but don't see any crashes, string
corruption or such. Could you check if you can repeat the behaviour
mentioned in the original bug report with the latest version of
imview, 1.1.8-3?
I can't, but I suspect that the original bug still exists.
When I select the .FIT file to open, versions 1.1.8-1 and 1.1.8-2 both
pop up a box about select the offsets, pixel type, endianness, etc..
But 1.1.8-3 has no such thing. FITS support is certainly broken,
since it seems to think that pixels are 1 byte each, but they are not.
Can you explain why the debian revisions act differently?
Image/Information/Path_to_Image seems corrupted in 1.1.8-3, anyway.
And valgrind still indicates some invalid read, after selecting
File/Open, but before selecting any file, among other warnings.
If there's a GPL compatible C or C++ library for reading FITS-files,
please let me know, I might add support for them at some point.
Reading 1,2, or 3-D FITS files should be pretty easy. Though there
are some variants, I have never seen them. You can google for the
fits definition document; the header is n 80-character ascii cards,
which must begin with SIMPLE, BITPIX, NAXIS, NAXIS[n]... in that
order. There are no newlines; use spaces as header filler, and NULL
as data filler. All fits sections are multiples of 2880 bytes. The
header is terminated by a line matching m/END {77}/.
Dimensions are given by NAXIS1,2, or 3; pixel size in bits is given by
BITPIX=8,16,32,-32,-64 and (experimental) 64. Data is MSB and
signed (except for BITPIX=8 I think which can be unsigned, but always
has the high bit clear..). You'll also want to read the BZERO and
BSCALE values, as well as possibly other reserved keywords, such as
BLANK.
The canonical library to access fits files is cfitsio, which is
already packaged (though I don't have any experience using it).
It is a GPL-compatible public domain work of the US Gov't, with a bit
of GPL gzip included.
--
Clear skies,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326971: imview: Loading image causes stack smash?
* Justin Pryzby: I was trying to load a FITS image, and I think I caused a stack smash. imview should certainly protect itself against that .. it should never read in more data than there is in a file (reading past the end of an mmap, or such), and it should never write more data to a buffer than the buffer can store. Could you provide the image for reference, so that we can reproduce the bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326971: imview: Loading image causes stack smash?
On Sat, Sep 17, 2005 at 06:37:37PM +0200, Florian Weimer wrote: * Justin Pryzby: I was trying to load a FITS image, and I think I caused a stack smash. imview should certainly protect itself against that .. it should never read in more data than there is in a file (reading past the end of an mmap, or such), and it should never write more data to a buffer than the buffer can store. Could you provide the image for reference, so that we can reproduce the bug? You could try one of the images on my website; say, http://justinpryzby.com/m27.0001.Dumbbell_Nebula.FIT [0]. I did File / Open / All Files (*.*), and got a dialog beginning with format not recognized. So I'm apparently supposed to give it hints about where the raster image data is inside that file. I looked at the header of the file: SIMPLE =T / http://fits.gsfc.nasa.gov./ BITPIX = 16 / Bits/pixel; 2s compliment MSB (big-end) integer NAXIS1 = 765 / Length of axis NAXIS2 = 510 / Length of axis BSCALE = 1.0 / Physical value = BZERO + pixel value * BSCALE BZERO = 32768.0 / Physical value = BZERO + pixel value * BSCALE and so entered into the X,Y,Z Dimensions fields 765,510,1, respectively. It is short/MSB type data, as per BITPIX. I don't know what Bands/Nb is, so I left it at its default: Nb=1. I set Skip=5760 because thats where the data begins. (Compute Header wont't work for FITS, usually, because both the header *and the data* are padded to a multiple of 2880 bytes.) Anyway, I pressed Try and got a new dialog: Coult not open ?^A, No such file or directory, followed by another dialog Read of garbage here failed, error=10. It occurs to me that imview is probably not sufficiently general to use FITS files. Integer FITS data is always stored as signed, and there are oftentimes keywords BSCALE and BZERO which must be used to interpret the data .. a given pixel value _a_ will have the physical value a*bscale+bzero, with units BUNITS, if specified. Maybe you can forward that upstream, and allow FITS to work with imview? Or even include full support for FITS? -- Clear skies, Justin References [0] A 20 minute exposure from a couple weeks ago, which includes a new nova alongside the popular deep-sky object M27. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326971: imview: Loading image causes stack smash?
Package: imview Version: 1.1.8-1 Severity: important Tags: security, upstream I was trying to load a FITS image, and I think I caused a stack smash. imview should certainly protect itself against that .. it should never read in more data than there is in a file (reading past the end of an mmap, or such), and it should never write more data to a buffer than the buffer can store. The reason I suspect a stacksmash is because the message I got was Cannot open ?^A, No such file or directory. That probably shouldn't happen. I strongly recommend that the upstream author uses valgrind: ==4431== ==4431== Invalid read of size 1 ==4431==at 0x1B9057F8: strlen (mac_replace_strmem.c:189) ==4431==by 0x1BB02078: std::string::string(char const*, std::allocatorchar const) (in /usr/lib/libstdc++.so.6.0.5) ==4431==by 0x8096B8B: (within /usr/bin/imview) ... ==4431== Address 0x52BFD66C is just below %esp. Possibly a bug in GCC/G++ ==4431== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==4431== Invalid read of size 1 ... ==4431== Address 0x52BFD66C is not stack'd, malloc'd or (recently) free'd ==4431== Conditional jump or move depends on uninitialised value(s) ==4431==at 0x1C2670FB: (within /lib/tls/libc-2.3.5.so) ==4431==by 0x1C24E3CE: vfprintf (in /lib/tls/libc-2.3.5.so) ==4431==by 0x1C2704E0: vsnprintf (in /lib/tls/libc-2.3.5.so) ==4431==by 0x81181E8: (within /usr/bin/imview) ==4431== Use of uninitialised value of size 4 ==4431==at 0x1B97C6A9: XftCharIndex (in /usr/lib/libXft.so.2.1.2) ==4431==by 0x1B978C6E: XftTextExtents8 (in /usr/lib/libXft.so.2.1.2) ==4431==by 0x811F3EF: (within /usr/bin/imview)
