Random failures when calling free()/malloc()

[Martin Schlemmer]

On Sun, 2003-07-20 at 22:16, Owen Taylor wrote:
> On Sun, 2003-07-20 at 09:14, Martin Schlemmer wrote:
> > On Sat, 2003-07-19 at 20:23, Owen Taylor wrote:
> > > 
> > > 
> > > This is classic memory corruption, probably a double free somewhere
> > > in your application.  It's certainly not libc, and unlikely
> > > to be GLib/GTK+ either... memory corruption failures are frequently
> > > not 'local' - a bug in one place will cause a crash somewhere 
> > > else.
> > > 
> > 
> > Btw, its not really 'my' application.  It does it with some of the
> > tests from glib-2.2.2 as well.
>
> OK, that makes it very likely that you have bad memory.
> If you have crashes with software that happens for nobody
> else, then look at your hardware.
>

No, check my previous mails - this box runs fine for a day with
memtest, and it builds the whole system from scratch and runs no
issues with older glibc.

> > This is where I want to ask something - are the  any known issues
> > with glib-2.2.* and latest cvs glibc+nptl ?  Most of the issues I
> > see have a g_free/g_new/g_malloc in there ...  glib-1.2* stuff is
> > fine though ...
>
> I bet it's just whatever is doing the most malloc traffic.

Check the very last mail I sent - its only when __STDC_ISO_10646__
support is compiled into glib2, and only with the later versions
of glibc.

I guess why its most obvious in glib, is because its about the only
lib that do anything utf8 on my system.  And I guess why glib-1.2
do not have issues, is because it do not properly support __STDC_ISO_10646__.

Question now - is it glib2, or glibc side that the problem lies ?  Or
could it be due to just a setup problem my side ?  Anything that is
critical for utf8 to work ?

In my last mail I did try to debug the crash extensively - please have
a look.  If anything more is required, let me know - as I will try anything,
but I have beaten my head against this wall for some time, so it could
be that I am missing the obvious problem.


Thanks,

-- 

Martin Schlemmer



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20030720/4f150c04/attachment.sig>