--nextPart1296748.DmgyH4dpz3
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Friday 13 November 2009 15:46:32 Raphael Kubo da Costa wrote:
> On Friday 13 November 2009 13:11:57 Alex Fiestas wrote:
> > Hi
> > Seems that MALLOC_CHECK_ feature of glibc is kind of broken in x86_64,
> >  giving false positives. In release mode this has no effect to the user,
> >  just when you're running KDE in development mode, MALLOC_CHECK_ will be
> >  set at 2, which means that malloc will abort the application when one =
of
> >  that false given errors happen.
> >
> > So I suggest to deactivate MALLOC_CHECK_ on 64 bits systems, at least
> > until it gets fixed.
> >
> > Some applications that usually crash on my system are:
> > - digikam (I'm in digikam sprint right now and I've asked gilles and he
> > agrees)
> > - kdevelop (I'm with apol here and he's concerned about this issue too).
> >
> > Everybody agrees with that?
> >
> > *http://techbase.kde.org/Development/malloc_check
>=20
> Are you sure about it being broken only in x86_64? I'm running x86 and
>  always get false positives too. I don't remember mpyne or maelcum
>  perceiving it as a 64-bit-only problem either.

Well I only run development on 64-bit so I can't say one way or the other=20
about 32-bit problems.  The initial bug reports all seemed to be x86_64 but=
=20
I've also seen complaints from users running 32-bit CPUs.

glibc 2.10+ is what affects us, I've never been able to figure out why,=20
maelcum managed to reduce or eliminate the crashes with the glibc experimen=
tal=20
malloc implementation IIRC (but the same switch didn't help me much as it=20
turns out).

My crash testcases are KNotify (all the damn time), JuK (if using phonon-gs=
t),=20
Konq (rarely) and KTorrent.  I'm not 100% convinced that only the malloc=20
checking code is affected, but I do know that if glibc in general is=20
corrupting memory no matter whether checking is enabled or disabled that I=
=20
should eventually get SIGSEGV in my testcases with checking disabled (and I=
=20
don't get that).

Oh, none of this happens if you export QT_NO_GLIB=3D1 before running your=20
preferred application...

I've been tracking this under bug 196207 [1] if anyone else has an idea wha=
t=20
to do to debug glibc ;)  I have not opened a glibc bug since I cannot drill=
=20
down to a small testcase (I suspect a threading torture test may do it but =
I=20
haven't tried).

[1] https://bugs.kde.org/show_bug.cgi?id=3D196207

Regards,
 - Michael Pyne

--nextPart1296748.DmgyH4dpz3
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iQIcBAABCAAGBQJK/jvdAAoJEAuvDJx7aunyhnEP/0m64cTfVNALgVVtsedK9y6b
6cud/JXGJeXmL0ugvcWKXT8FMyP02OkAvqrDuMoFypB/zcfYY91Ye0sutcDGbXta
mS9yKfSY60NLsWsADF7CBryHtpDUZgl0Nc3o93DwL8Fo0lRMPcdAJbx5wuoZAA6h
K+f/mbGD82h+5//bx18SIFEaOcXEtQy5owqNJS1eRwYJ4jD1BrJCBHhdGGSyukic
NIzMq95n4bM9WFjo2EFXuufQ+IbHqFcqKsnN7EQTIW7sVnZtdLnuB/xbdICwn5dT
vfvfr47RaBIXXocfRzxUrCi9U+Y/i8ogTC16lnyd/2r6AOhZE5TwMmukl4Y889wO
hlqjzaYB45J3eBe8c73+AVjB8penxNhYgMABC/qNCmi73Tso/WYWMw2S4B85zwVI
P0W/qgHVdSiZodIJ+YdVPmxi/CeZcO3AeXuxfVhRbYZqJz7lkry023iX+aYWLskU
imZwjwJ3OgOUJ1J9CM3ELJZvkMum5ZK/26IRq3rzpEiVFcT9oCp0YQtwr68Igm6g
77X63nahZ2LB95AukQpHbhQ03uLLajrWiDRtYbYOUAlGpH3a4734WTl1LZo69HCr
HZyxeImqRrIcUTYe4VAEoiDQjLsVv3k4I26OGPZIOMzXKYkcwyZ1728UbcAycgh0
jerelg5Wzmrt+dhVALyN
=TiyX
-----END PGP SIGNATURE-----

--nextPart1296748.DmgyH4dpz3--