don't let Inkscape crash - prefer g_try_new over g_new
According to the glib manual for g_try_new: http://library.gnome.org/devel/glib/unstable/glib-Memory-Allocation.html#g-t...
"Attempts to allocate n_structs elements of type struct_type, and returns NULL on failure. Contrast with g_new(), which aborts the program on failure. The returned pointer is cast to a pointer to the given type. If n_structs is 0 it returns NULL. ... Since 2.8"
Can we assume that everyone uses glib 2.8? I already commited patch svn rev 21327 that uses g_try_new ...
Adib. ---
the Adib wrote:
Can we assume that everyone uses glib 2.8? I already commited patch svn rev 21327 that uses g_try_new ...
The minimum GTK requirement is currently 2.10, and the roadmap says it will be 2.12 for 0.47. This implies Glib at least 2.14. So your patch won't lock anybody out.
OT: It's quite annoying that there seems to be no indication of which Glib version is required for a given GTK release...
Regards, Krzysztof Kosiński
On May 12, 2009, at 10:15 AM, Krzysztof Kosiński wrote:
the Adib wrote:
Can we assume that everyone uses glib 2.8? I already commited patch svn rev 21327 that uses g_try_new ...
The minimum GTK requirement is currently 2.10, and the roadmap says it will be 2.12 for 0.47. This implies Glib at least 2.14. So your patch won't lock anybody out.
Just be aware that the roadmap is not a binding document.
That is, anything thrown up there is just a suggestion. Also it is sometimes quite out of date.
Hmmm... seems that the version is wrong for 0.47 that you mentioned.
The newer page for tracking such details is at
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
Ubuntu 7.10 has hit end-of-life, but Ubuntu 6.06 is still a supported release. That only has Glib 2.10.2 and Gtk 2.8.10, therefore...
The minimum is quite different.
Also, I've had to fix some issues for glib compatibility myself just within the last few weeks (one of my changes had broken things for Bulia). So those lower requirements are recent.
Could this prevent even a handful of potential segfaults? I have no clue, that's why I ask.
sent from g1
On May 12, 2009 7:40 PM, "Jon A. Cruz" <jon@...18...> wrote:
On May 12, 2009, at 10:15 AM, Krzysztof Kosiński wrote: > the Adib wrote: >>
Can we assume t...
Just be aware that the roadmap is not a binding document.
That is, anything thrown up there is just a suggestion. Also it is sometimes quite out of date.
Hmmm... seems that the version is wrong for 0.47 that you mentioned.
The newer page for tracking such details is at
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
Ubuntu 7.10 has hit end-of-life, but Ubuntu 6.06 is still a supported release. That only has Glib 2.10.2 and Gtk 2.8.10, therefore...
The minimum is quite different.
Also, I've had to fix some issues for glib compatibility myself just within the last few weeks (one of my changes had broken things for Bulia). So those lower requirements are recent.
------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I must say, the title "Don't let Inkscape Crash" is probably the best title for a bug ever filed for IS.
It is maybe dating me, but in the past, if a malloc() causes problems, it is because somebody has done something bad with a previously- allocated malloc() chunk.
bob
On 5/11/2009 5:14 PM, the Adib wrote:
According to the glib manual for g_try_new: http://library.gnome.org/devel/glib/unstable/glib-Memory-Allocation.html#g-t...
"Attempts to allocate n_structs elements of type struct_type, and returns NULL on failure. Contrast with g_new(), which aborts the program on failure. The returned pointer is cast to a pointer to the given type. If n_structs is 0 it returns NULL. ... Since 2.8"
Can we assume that everyone uses glib 2.8? I already commited patch svn rev 21327 that uses g_try_new ...
Bob Jamison wrote:
I must say, the title "Don't let Inkscape Crash" is probably the best title for a bug ever filed for IS.
It is maybe dating me, but in the past, if a malloc() causes problems, it is because somebody has done something bad with a previously- allocated malloc() chunk.
Indeed, it seems odd to "fix" Inkscape by letting g_(try_)new fail silently, possibly creating problems at a later date or masking previous problems... Or did most of the code using g_new simply assume that it would return a null pointer (handling it appropriately)?
On Wed, May 13, 2009 at 9:11 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Bob Jamison wrote:
I must say, the title "Don't let Inkscape Crash" is probably the best title for a bug ever filed for IS.
It is maybe dating me, but in the past, if a malloc() causes problems, it is because somebody has done something bad with a previously- allocated malloc() chunk.
Indeed, it seems odd to "fix" Inkscape by letting g_(try_)new fail silently, possibly creating problems at a later date or masking previous problems... Or did most of the code using g_new simply assume that it would return a null pointer (handling it appropriately)?
Of course you have to test the returning pointer if this is NULL. But g_new simply ABORTS the program.
The current problems occurs in pixbuf allocations where the calculated dimensions are far from being realistic. But g_new is also used in some filter codes where it allocates only small chunks and so assumes that it is enough memory out there. Unfortunately Inkscape can not handle situations where the allocation (which reason does not matter) fails.
HTH, Adib.
participants (6)
-
Bob Jamison -
Jasper van de Gronde -
Jon A. Cruz -
Josh Andler -
Krzysztof Kosiński -
the Adib