Re: issue with libthr?

On 4/06/2013 2:54 AM, Waitman Gobble wrote:
> On Mon, 3 Jun 2013 07:55:54 -0700, Marcel Moolenaar <marcel_at_xcllnt.net> 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:=20
>>>> =20
>>>> On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
>>>>> =20
>>>>> Hi,
>>>>> =20
>>>>> I'm getting a ton of core dumps from Python and any software that =
>> uses
>>> Python,
>>>>> ie has USE_PYTHON_BUILD=3Dyes in Makefile.
>>>>> =20
>>>>> 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)
>>>>> =20
>>>>> 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.
>>>> =20
>>>> 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.
>>>> =20
>>>> Reverting r250991 and rebuilding libc solves the issue for me:
>>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D250991
>>>> =20
>>>>> =20
>>> =20
>>> Thanks for the info, I appreciate it. I had a heck of a time getting
>>> database/py-sqlite3 to build as well.=20
>>> 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
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- 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 =3D """
>> + src/prep_cif.c
>> + src/closures.c
>> +-src/dlmalloc.c
>> + """.split()
>> +=20
>> + ffi_platforms =3D {
>>
>>
>> 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.
>>
>> FYI,
>>
>> --=20
>> Marcel Moolenaar
>> marcel_at_xcllnt.net
>>
>>
>>
> 
> 
> yes, that patch seems to work on my machine. After rebuilding Python with the
> patch, I was able to install databases/py-sqlite3 without error, also the
> www/midori port now builds and installs without crashing. I'll let you know if
> I see any problems.
> 
> Thank you,
> 

Great work Marcel :)

What needs to be done to get this upstreamed?

Koobs