Re: issue with libthr?

From: Waitman Gobble <uzimac_at_da3m0n8t3r.com>
Date: Sat, 1 Jun 2013 11:14:46 -0700 (PDT)
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. 




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
Received on Sat Jun 01 2013 - 16:14:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC