Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Jun 2013 08:20:43 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Waitman Gobble <uzimac@da3m0n8t3r.com>
Cc:        FreeBSD-CURRENT@freebsd.org
Subject:   Re: issue with libthr?
Message-ID:  <20130602052043.GA3047@kib.kiev.ua>
In-Reply-To: <20130602040301.C44A836F49EC@dx.burplex.com>
References:  <20130602040301.C44A836F49EC@dx.burplex.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--gdrMpCAa6ebg9u4r
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 01, 2013 at 09:03:01PM -0700, Waitman Gobble wrote:
> On Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble
> <uzimac@da3m0n8t3r.com> wrote:=20
> >
> >On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov
> <kostikbel@gmail.com>
> >wrote:=20
> >>
> >>
> >>
> >>You cannot even guess what is going on without a proper debug informati=
on.
> >>Recompile and reinstall the libc/libthr/rtld with the debugging symbols
> >>to get proper backtraces.
> >>
> >>Anyway, two backtraces you demostrated, although not giving much useful
> >>data, look very different.  More, the second backtrace suggests that
> >>there is either a bug in python interposing of malloc or memory
> corruption.
> >
> >
> >Thanks so much for your help, I'll rebuild with debug on next.=20
> >
>=20
>=20
> Hello,
>=20
> Perhaps a better backtrace, from python2.7.core created when trying to in=
stall
> www/midori
>=20
> #0  thr_kill () at thr_kill.S:3
> #1  0x0000000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #2  0x000000080464aca1 in free (mem=3D0x8065015b0)
>     at
> /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlm=
alloc.c:4350
> #3  0x0000000800e4c1af in _pthread_mutex_destroy (mutex=3D<value optimized
> out>)
>     at /usr/src/lib/libthr/thread/thr_mutex.c:273
> #4  0x00000008010e0def in closedir (dirp=3D0x803b2dda0)
>     at /usr/src/lib/libc/gen/closedir.c:65
> #5  0x000000000053d482 in posix_listdir (self=3D0x0, args=3D0x806425ae0)
>     at ./../Modules/posixmodule.c:2543
> #6  0x000000000057fa6e in PyCFunction_Call (func=3D0x801920080, arg=3D0x8=
06425ae0,
>=20
>     kw=3D0x0) at ./../Objects/methodobject.c:81
> #7  0x00000000004e40dd in call_function (pp_stack=3D0x7fffffff9388, oparg=
=3D1)
>     at ./../Python/ceval.c:4021
> #8  0x00000000004dffcd in PyEval_EvalFrameEx (f=3D0x801a8f9a0, throwflag=
=3D0)
>     at ./../Python/ceval.c:2666
>=20
> snipped, complete backtrace at https://dx.burplex.com/backtrace.txt
This seems to confirm that python interposed the free() function.
Also, the python' version of free() raised an assert, which caused
the coredump.

I have no idea why it did this, and what condition check failed.  This is
probably a subject to talk with python maintainers.

>=20
>=20
> all ports have been rebuilt, lib_pkgchk returns no missing libraries.
> running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun  1 03:21:48 PDT 2013
>=20
> It seems that any program using Python crashes. also, Seamonkey. I do not=
 so
> far notice
>  any other issues with this system. It was working great until an update =
about
> a week ago.
>=20
> seamonkey
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x000000080316b585 in XRE_InstallX11ErrorHandler ()
>    from /usr/local/lib/seamonkey/libxul.so
> #2  0x0000000800f75286 in handle_signal (actp=3D<value optimized out>, si=
g=3D11,
>=20
>     info=3D0x7fffffffb7f0, ucp=3D0x7fffffffb480)
>     at /usr/src/lib/libthr/thread/thr_sig.c:237
> #3  0x0000000800f74e89 in thr_sighandler (sig=3D11, info=3D<value optimiz=
ed out>,
>=20
>     _ucp=3D<value optimized out>) at /usr/src/lib/libthr/thread/thr_sig.c=
:182
> #4  0x00007ffffffff1d3 in ?? ()
> #5  0x0000000800f74d70 in sigaction ()
>     at /usr/src/lib/libthr/thread/thr_sig.c:574
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently asm

This one is only the past some event, the backtrace shows the internal
work of the libthr handling of the signal.  Why signal was raised is
up to the application.

--gdrMpCAa6ebg9u4r
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)

iQIcBAEBAgAGBQJRqtYqAAoJEJDCuSvBvK1B6YcQAJR6NuOG65TLd1bI34Y3cbZy
cqmeD+Bh7iSiIYSbBzajGgIt830UC4eZbtYxVBCo8KAEkgsBmVGvbf+ZTpmqKjTX
N/YQHqmpINFaF8QXJd54ChFjeIwRxbsbagLKf4F+pesCQkYHDARSxClP2v/1ulAO
5E0p395+icg0ZexRavNH3as71HwEt6XvGs0hSTDHI4RHzKfNiGFVkao/W8myMnV/
hZjJ9ofA4y6Ik9hJ7a/vvsSBRdZxKRVmeZQTudJXwy0evxj4KyPhMIW7bCSofBPC
nLeGMPqRlm0oC/dciKE+CtV7Evr/TRxqHybgmKaSzDShu8AuHg+HxhED5A+N1LlR
UK+NyIR1iXxovyY4bDJnQLuIHfAo3V1U1vPh0/ZDcO669aZvn+lJG2WbLxZG8kxV
VuAlQK413YFgdwEmMbk2s7qcqUvibQ/kN5aurBEVt8m81wIpHKJQp4UcwokfHRKq
OnmFScQ/uC1qgvovRwCFOoW+Q8aWMWbfp94rD3u4L3JklUsi4ISKG79u3gVjN2gr
GEPNFJeQ7Dd9zzhBUEleBVi7DH73fxf50ATby0YJPgOBOqzWQApZOUMfQdZr7RCX
GOVw1FgP9VVyt+gsf3R0rLBxuKZ3qNP6ncYhKgUM1mw+Vme4SpywkrckFYvWRPZ+
DVRIEIgm04+WJvBbGoMG
=quVX
-----END PGP SIGNATURE-----

--gdrMpCAa6ebg9u4r--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130602052043.GA3047>