Re: issue with libthr?

On Mon, Jun 03, 2013 at 07:55:54AM -0700, Marcel Moolenaar wrote:
> 
> On Jun 2, 2013, at 8:08 AM, Waitman Gobble <uzimac_at_da3m0n8t3r.com> wrote:
> 
> > On Sun, 2 Jun 2013 10:43:35 -0400, Mark Johnston <markj_at_freebsd.org> wrote: 
> >> 
> >> On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> I'm getting a ton of core dumps from Python and any software that uses
> > Python,
> >>> ie has USE_PYTHON_BUILD=yes in Makefile.
> >>> 
> >>> hundreds of msgs in dmesg:
> >>> pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> >>> pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> >>> pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> >>> pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> >>> pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped)
> >>> 
> >>> from gdb it seems to me to be libthr related? I've noticed a couple updates
> > in
> >>> May.. wonder if it's related? I've only noticed this issue in the past
> > week,
> >>> after a complete rebuild and updated.
> >> 
> >> I've been running into this issue too - python 2.7 would crash when
> >> trying to rebuild databases/tdb and databases/py-sqlite3 with backtraces
> >> similar to what you have below. The python port itself hasn't changed in
> >> a while.
> >> 
> >> Reverting r250991 and rebuilding libc solves the issue for me:
> >> http://svnweb.freebsd.org/base?view=revision&revision=250991
> >> 
> >>> 
> > 
> > Thanks for the info, I appreciate it. I had a heck of a time getting
> > database/py-sqlite3 to build as well. 
> > My workaround to get it installed was to change the Makefile in WRKSRC
> 
> 
> Can you apply the following patch to /usr/ports/lang/python27, rebuild
> python, re-install and then try to build databases/py-sqlite3 again?
> 
> Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
> ===================================================================
> --- files/patch-Modules-_ctypes-libffi-fficonfig.py.in	(revision 0)
> +++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in	(working copy)
> _at__at_ -0,0 +1,10 _at__at_
> +--- Modules/_ctypes/libffi/fficonfig.py.in.orig	2013-06-03 07:16:44.000000000 -0700
> ++++ Modules/_ctypes/libffi/fficonfig.py.in	2013-06-03 07:17:03.000000000 -0700
> +_at__at_ -1,7 +1,6 _at__at_
> + ffi_sources = """
> + src/prep_cif.c
> + src/closures.c
> +-src/dlmalloc.c
> + """.split()
> + 
> + ffi_platforms = {
> 
> 
> It seems the root cause is a broken python build that accidentally
> defines malloc(), free(), at al in _ctypes.so. A longer explanation
> was sent to svn-src-head_at_ and svn-src-all_at_
> 
> I expect that the patch also fixes the other problems mentioned in
> this thread. It would be great if people can verify this.

I can confirm that this fixes the problems I had building databases/tdb
and databases/py-sqlite3. I haven't done any other testing though.

-Mark