# To subscribers of the xforms list from Jens Thoms Toerring <Jens.Toerring@physik.fu-berlin.de> :
Hi,
unfortunately, my problem with dumping a pixmap into a file using
the flimage_xxx() functions I wrote about some time ago persists,
i.e. I still get a segmentation fault during flimage_free().
Following spl's advice I use now a very simple routine:
int dump_pixmap( Pixmap pm )
{
FL_IMAGE *fl_image;
if ( ( fl_image = flimage_alloc( ) ) == NULL )
return 0;
flimage_from_pixmap( fl_image, pm );
flimage_dump( fl_image, "/tmp/xx.ppm", "PPM" );
flimage_free( fl_image );
return 1;
}
I guess such a simple function should be virtually immune to problems
due to (hopefully non-existent ;-) memory corruption from other parts
of the program - all memory allocated here is free()'d immediately
again and no other functions not from the XForms library have a chance
to mess with the memory in between. (Well, to be honest, except a
signal handler, but I am quite convinced that it's clean.) And finally,
the pixmap exists - I now use my own routine to dump it to a file which
works flawlessly, only if I use the flimage_xxx() routines instead
there is this little problem.
Using my own little tool for memory debugging I see the following
requests from this function (first number is the address of the
memory chunk allocateded or freed, the number in parentheses is
the size):
calloc: 0x81c02d8 (1020)
calloc: 0x81c06f0 (120)
realloc: 0x81c06f0 -> 0x81c06f0 (160)
realloc: 0x81c06f0 -> 0x81c06f0 (200)
realloc: 0x81c06f0 -> 0x81c06f0 (240)
realloc: 0x81c06f0 -> 0x81c06f0 (280)
malloc: 0x81c0820 (1024)
malloc: 0x81c1f00 (1024)
malloc: 0x81c2318 (1764)
calloc: 0x40963018 (242000)
malloc: 0x81c2a18 (1764)
calloc: 0x4099f018 (242000)
malloc: 0x81c3118 (1764)
calloc: 0x409db018 (242000)
malloc: 0x81c3818 (1764)
calloc: 0x40a17018 (242000)
free: 0x40963018
free: 0x81c2318
free: 0x4099f018
free: 0x81c2a18
free: 0x409db018
free: 0x81c3118
free: 0x40a17018
free: 0x81c3818
And the last line is where I always get the segmentation fault, i.e.
after freeing the fourth of the big chunks. The size of the pixmap is
550x440, which nicely fits the calloc() calls asking for 242000 bytes
(but why 4 of them - I would have expected only 3 for a rgb picture...)
But it does not depend on the size of the image, using e.g. a smaller
pixmap I get exactly the same results.
I don't know if this is of any relevance but I just want to mention that
dumping the pixmap happens from within an idle handler.
All this runs on a Linux (2.4.10, 2.4.17) machine with libc 2.2.4 and,
if I can trust <forms.h>, XFORMS version 0.89, fixlevel 6.
By the way, I have also another, non-related problem with the
flimage_dump() function, and that's that you have to append the image
type as the extension to the file name. While I am sure that this is
very convenient in most cases it introduces some problems for me because
I need to dump the image into a temporary file. And when getting a
temporary file with mkstemp(), which is, as far as I know, the only
recommended because safe method, I get a file name that has no extension
that I could choose, but 6 random characters at the end. Thus it might
probably be rather useful (also for cases where one wants to pipe the
file to another process instead of a real file) to be able to dump the
image to an already opened stream or file descriptor.
Thanks for your attention, Jens
--
_ _____ _____
| ||_ _||_ _| Jens.Toerring@physik.fu-berlin.de
_ | | | | | | AG Moebius, Institut fuer Molekuelphysik
| |_| | | | | | Fachbereich Physik, Freie Universitaet Berlin
\___/ens|_|homs|_|oerring Tel: ++49 (0)30 838 - 53394 / FAX: - 56046
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Wed May 01 2002 - 13:54:17 EDT