Re: issue with libthr?

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_at_da3m0n8t3r.com> wrote: 
> >
> >On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov
> <kostikbel_at_gmail.com>
> >wrote: 
> >>
> >>
> >>
> >>You cannot even guess what is going on without a proper debug information.
> >>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. 
> >
> 
> 
> Hello,
> 
> Perhaps a better backtrace, from python2.7.core created when trying to install
> www/midori
> 
> #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=0x8065015b0)
>     at
> /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350
> #3  0x0000000800e4c1af in _pthread_mutex_destroy (mutex=<value optimized
> out>)
>     at /usr/src/lib/libthr/thread/thr_mutex.c:273
> #4  0x00000008010e0def in closedir (dirp=0x803b2dda0)
>     at /usr/src/lib/libc/gen/closedir.c:65
> #5  0x000000000053d482 in posix_listdir (self=0x0, args=0x806425ae0)
>     at ./../Modules/posixmodule.c:2543
> #6  0x000000000057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0,
> 
>     kw=0x0) at ./../Objects/methodobject.c:81
> #7  0x00000000004e40dd in call_function (pp_stack=0x7fffffff9388, oparg=1)
>     at ./../Python/ceval.c:4021
> #8  0x00000000004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0)
>     at ./../Python/ceval.c:2666
> 
> 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.

> 
> 
> 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
> 
> 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.
> 
> 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=<value optimized out>, sig=11,
> 
>     info=0x7fffffffb7f0, ucp=0x7fffffffb480)
>     at /usr/src/lib/libthr/thread/thr_sig.c:237
> #3  0x0000000800f74e89 in thr_sighandler (sig=11, info=<value optimized out>,
> 
>     _ucp=<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.