issue with libthr?

[Marcel Moolenaar]

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)
@@ -0,0 +1,10 @@
+--- 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
+@@ -1,7 +1,6 @@
+ 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@ and svn-src-all@

I expect that the patch also fixes the other problems mentioned in
this thread. It would be great if people can verify this.

FYI,

-- 
Marcel Moolenaar
marcel at xcllnt.net