Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
- From: Sven Neumann <sven gimp org>
- To: "Eric M. Monsler" <emonsler beamreachnetworks com>
- Cc: gtk-app-devel-list <gtk-app-devel-list gnome org>, "gtk-list gnome org" <gtk-list gnome org>, Christopher Keller <CKeller BeamReachNetworks com>
- Subject: Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
- Date: 12 Aug 2002 23:07:51 +0200
Hi,
"Eric M. Monsler" <emonsler beamreachnetworks com> writes:
I'm jumping lists with this; my apologies, but it's definitely a gtk
bug and so want to followup to gtk-list.
the correct place to report this would probably have been
http://bugzilla.gnome.org/.
If I try to print a denormalized float with a specific format string,
e.g. "%6.2f\n", using g_string_sprintf(), the program crashes with an
error about allocating a negative number of bytes.
An example program is below, showing the error when compiled and run
under Linux. I believe that the problem is present in both 1.2.9 and
1.2.10.
I can reproduce the problem with gtk+-1.2.10 (or actually glib-1.2.10)
running under Linux on an i686:
GLib-ERROR **: could not allocate -6 bytes
aborting...
have two questions:
1) Is there ongoing bugfix developement on 1.2.x GTK+?
2) Is this bug fixed in Gtk+ 2.0.x?
it seems to work better with GTK+-2.0 (or actually glib-2.0):
0.00
I am seeing a crash, although with GLib error message, when printing
a floating point number.
The error message is that GLib is unable to allocate -7 bytes.
Which seems reasonable enough.
The problem is that the data I am trying to print does not seem to
be a valid floating point number. My program needs to be
crash-proof in this case, as bad data is going to be encountered. I
see that the value that is bad is typically something like
"6.0245e-44", which is not valid.
The fact that I can read the value means that ddd/gdb is handling it
properly, but not g_string_sprintf.
Any clues? Any suggestions as to how to clamp the floating point
value? I have tried to do so with comparisons to MAX_FLT and
MIN_FLT, without success.
I don't think you can reliably perform range tests on uninitialized
memory since the compiler knows about the fact that the value was
never initialized and may optimize the range check away.
Salut, Sven
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]