[Bug 196207] GTK/Glib applications crash when running under KDE4.3x (malloc_printerr, free(): invalid pointer)

George Kiagiadakis gkiagiad at csd.uoc.gr
Tue Jun 16 13:30:36 BST 2009


https://bugs.kde.org/show_bug.cgi?id=196207


George Kiagiadakis <gkiagiad at csd.uoc.gr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gkiagiad at csd.uoc.gr




--- Comment #29 from George Kiagiadakis <gkiagiad csd uoc gr>  2009-06-16 14:30:30 ---
Quoting the malloc(3) man page:

Recent versions of Linux libc (later than 5.4.23) and glibc (2.x) include a
malloc() implementation which is tunable via environment variables.  When
MALLOC_CHECK_ is set, a special (less efficient) implementation is used which
is designed to be tolerant against simple errors, such as double  calls of 
free() with the same argument, or overruns of a single byte (off-by-one bugs). 
Not all such errors can be protected against, however, and memory leaks can
result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently
ignored; if set to 1, a diagnostic message  is  printed  on stderr; if set to
2, abort(3) is called immediately; if set to 3, a diagnostic message is printed
on stderr and the program is aborted.  Using a non-zero MALLOC_CHECK_ value can
be useful because otherwise a crash may happen much later, and the true cause
for the problem is then very hard to track down.
--------

That means that all the gtk apps that crash *do* experience heap corruption and
thus are buggy! If you want a permanent and correct fix for those crashes, file
bug reports for these applications. Setting MALLOC_CHECK_ to 0 is just a
workaround to silently ignore the real problem, and in fact if those apps don't
crash with MALLOC_CHECK_=0, they are working out of luck!

Thanks.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Unassigned-bugs mailing list