From owner-freebsd-current@FreeBSD.ORG  Sat Jun  1 18:14:47 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: FreeBSD-CURRENT@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id 570EF3D0
 for <FreeBSD-CURRENT@FreeBSD.org>; Sat,  1 Jun 2013 18:14:47 +0000 (UTC)
 (envelope-from daemon@dx.burplex.com)
Received: from dx.burplex.com (dx.burplex.com [50.197.134.185])
 by mx1.freebsd.org (Postfix) with ESMTP id 474F7A03
 for <FreeBSD-CURRENT@FreeBSD.org>; Sat,  1 Jun 2013 18:14:47 +0000 (UTC)
Received: by dx.burplex.com (Postfix, from userid 1)
 id 75A1736F489C; Sat,  1 Jun 2013 11:14:46 -0700 (PDT)
To: Konstantin Belousov <kostikbel@gmail.com>
Subject: Re: issue with libthr?
From: Waitman Gobble <uzimac@da3m0n8t3r.com>
X-UUID-HOR: dee89fc1-cae2-11e2-a1b3-902b34a86bc3
Message-Id: <20130601181446.75A1736F489C@dx.burplex.com>
Date: Sat,  1 Jun 2013 11:14:46 -0700 (PDT)
Cc: FreeBSD-CURRENT@FreeBSD.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jun 2013 18:14:47 -0000

On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov <kostikbel@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. 




One thing I can get an instant crash is building midori, so I've been
experimenting to see where it's breaking.

It seems two things in the build script cause it wreck python:

the midori build reconstitutes a binary coded file within the script, it's a
file t.bz, which is uncompressed to become wafadmin, 
inside that is a file Tools/config_c.py

there's
p.Utils.pproc.Popen in 'cmd_and_log' function 

it returns:
p: 
{'_child_created': True, 'returncode': 1, 'stdout': <closed file '<fdopen>',
mode 'rb' at 0x8037e92e0>, 'stdin': None, 'pid': 62571, 'stderr': <closed file
'<fdopen>', mode 'rb' at 0x8037e8b60>, 'universal_newlines': False}

the '1' returncode causes build to fail.. 


Also, function def validate_c(self,kw) 
*always* causes python to crash

for example, when it calls 
conf.check (header_name='unistd.h')
..core dump...


Maybe this isn't useful information.. Next I'll rebuild with debug and see
about getting more info from gdb.

Thanks,

--
Waitman Gobble
San Jose California USA
+1.5108307875