security/openssl vs. lang/python27 threads

benschumacher

benschumacher

This is an extremely confusing issue, but I'm having a problem getting lang/python27 to work with the OpenSSL port when both are compiled with THREADS enabled. The issue exhibits itself when I try to install devel/py-distribute in the form of a segfault:

Code: 
$ sudo make install
===>  Installing for py27-distribute-0.6.35
===>   py27-distribute-0.6.35 depends on file: /usr/local/bin/python2.7 - found
===>   py27-distribute-0.6.35 depends on executable: python - found
PKG_PREFIX=/usr/local /bin/sh /usr/ports/devel/py-distribute/work/pkg-install py27-distribute-0.6.35 PRE-INSTALL
===>   Generating temporary packing list
===>  Checking if devel/py-distribute already installed
*** Signal 11

Stop in /usr/ports/devel/py-distribute.

I've verified that if I reinstall lang/python27 and don't compile with THREADS, then it works. Ugh. It is highly confusing since both ports enable THREADS by default. Any guidance would be appreciated. Thanks.

My system:

Code: 
$ uname -srm
FreeBSD 9.0-RELEASE amd64
 
Please upgrade to 9.1, 9.0 has been end-of-life for a while now. It's possible 9.0 has a few bugs that have been fixed in 9.1.

[thread=40469]Topics about unsupported FreeBSD versions[/thread]
 
While I take your point (it seems totally valid), I'm a little disappointed to give up my 400+ days of uptime.

Code: 
$ uptime
10:21AM  up 432 days, 21:25, 8 users, load averages: 0.19, 0.21, 0.19

If I may interpret your statement, you believe that there could be a threading issue in FreeBSD 9.0 that's causing my issue?

Just for fun, I rebuilt lang/python27 with THREADS and collected the backtrace from the segfault:

Code: 
$ gdb --args python $(which pip)
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
(gdb) r
Starting program: /usr/local/bin/python /usr/local/bin/pip
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 2021498]
(no debugging symbols found)...(no debugging symbols found)...[New Thread 801407400 (LWP 2021498/python2.7)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 801407400 (LWP 2021498/python2.7)]
0x0000000803bcc680 in EVP_PKEY_CTX_dup () from /usr/local/lib/libcrypto.so.8
(gdb) info threads
* 2 Thread 801407400 (LWP 2021498/python2.7)  0x0000000803bcc680 in EVP_PKEY_CTX_dup () from /usr/local/lib/libcrypto.so.8
(gdb) bt
#0  0x0000000803bcc680 in EVP_PKEY_CTX_dup ()
   from /usr/local/lib/libcrypto.so.8
#1  0x0000000803bbfb9f in EVP_MD_CTX_copy_ex ()
   from /usr/local/lib/libcrypto.so.8
#2  0x0000000803666cc0 in EVPnew ()
   from /usr/local/lib/python2.7/lib-dynload/_hashlib.so
#3  0x0000000803666fb0 in EVP_new_md5 ()
   from /usr/local/lib/python2.7/lib-dynload/_hashlib.so
#4  0x0000000000483d53 in PyEval_EvalFrameEx ()
#5  0x00000000004842fa in PyEval_EvalFrameEx ()
#6  0x0000000000485890 in PyEval_EvalCodeEx ()
#7  0x0000000000485b92 in PyEval_EvalCode ()
#8  0x0000000000494629 in PyImport_ExecCodeModuleEx ()
#9  0x0000000000494b64 in PyImport_ImportFrozenModule ()
#10 0x0000000000495bc2 in PyImport_ReloadModule ()
#11 0x000000000049603f in PyImport_ReloadModule ()
#12 0x0000000000496c60 in PyImport_ImportModuleLevel ()
#13 0x000000000047e459 in _PyBuiltin_Init ()
#14 0x0000000000418fcc in PyObject_Call ()
#15 0x000000000047e945 in PyEval_CallObjectWithKeywords ()
#16 0x0000000000481a8d in PyEval_EvalFrameEx ()
#17 0x0000000000485890 in PyEval_EvalCodeEx ()
#18 0x0000000000485b92 in PyEval_EvalCode ()
#19 0x0000000000494629 in PyImport_ExecCodeModuleEx ()
#20 0x0000000000494b64 in PyImport_ImportFrozenModule ()
#21 0x0000000000495bc2 in PyImport_ReloadModule ()
#22 0x000000000049607f in PyImport_ReloadModule ()
#23 0x0000000000496c60 in PyImport_ImportModuleLevel ()
#24 0x000000000047e459 in _PyBuiltin_Init ()
#25 0x0000000000418fcc in PyObject_Call ()
#26 0x000000000047e945 in PyEval_CallObjectWithKeywords ()
#27 0x0000000000481a8d in PyEval_EvalFrameEx ()
#28 0x0000000000485890 in PyEval_EvalCodeEx ()
#29 0x0000000000485b92 in PyEval_EvalCode ()
#30 0x0000000000494629 in PyImport_ExecCodeModuleEx ()
#31 0x0000000000494b64 in PyImport_ImportFrozenModule ()
#32 0x0000000000496342 in PyImport_ReloadModule ()
#33 0x0000000000495bc2 in PyImport_ReloadModule ()
#34 0x0000000000495e39 in PyImport_ReloadModule ()
#35 0x0000000000496e17 in PyImport_ImportModuleLevel ()
#36 0x000000000047e459 in _PyBuiltin_Init ()
#37 0x0000000000418fcc in PyObject_Call ()
#38 0x000000000047e945 in PyEval_CallObjectWithKeywords ()
#39 0x0000000000481a8d in PyEval_EvalFrameEx ()
#40 0x0000000000485890 in PyEval_EvalCodeEx ()
#41 0x0000000000485b92 in PyEval_EvalCode ()
#42 0x0000000000494629 in PyImport_ExecCodeModuleEx ()
#43 0x0000000000494b64 in PyImport_ImportFrozenModule ()
#44 0x0000000000495bc2 in PyImport_ReloadModule ()
#45 0x000000000049603f in PyImport_ReloadModule ()
#46 0x0000000000496c98 in PyImport_ImportModuleLevel ()
#47 0x000000000047e459 in _PyBuiltin_Init ()
#48 0x0000000000418fcc in PyObject_Call ()
#49 0x000000000047e945 in PyEval_CallObjectWithKeywords ()
#50 0x0000000000481a8d in PyEval_EvalFrameEx ()
#51 0x0000000000485890 in PyEval_EvalCodeEx ()
#52 0x0000000000485b92 in PyEval_EvalCode ()
---Type <return> to continue, or q <return> to quit---
#53 0x0000000000494629 in PyImport_ExecCodeModuleEx ()
#54 0x0000000000494b64 in PyImport_ImportFrozenModule ()
#55 0x0000000000496342 in PyImport_ReloadModule ()
#56 0x0000000000495bc2 in PyImport_ReloadModule ()
#57 0x000000000049603f in PyImport_ReloadModule ()
#58 0x0000000000496c60 in PyImport_ImportModuleLevel ()
#59 0x000000000047e459 in _PyBuiltin_Init ()
#60 0x0000000000483d53 in PyEval_EvalFrameEx ()
#61 0x0000000000485890 in PyEval_EvalCodeEx ()
#62 0x0000000000484019 in PyEval_EvalFrameEx ()
#63 0x00000000004842fa in PyEval_EvalFrameEx ()
#64 0x00000000004842fa in PyEval_EvalFrameEx ()
#65 0x0000000000485890 in PyEval_EvalCodeEx ()
#66 0x0000000000485b92 in PyEval_EvalCode ()
#67 0x000000000049f9e2 in Py_CompileString ()
#68 0x000000000049fab6 in PyRun_FileExFlags ()
#69 0x00000000004a0f8b in PyRun_SimpleFileExFlags ()
#70 0x0000000000414d67 in Py_Main ()
#71 0x000000000041401a in main ()
(gdb)

I think I'll also go ahead try to do debug builds of security/openssl and lang/python27 in a jail -- it'd be nice to try to eliminate potential issues in the ports before I go through an OS upgrade.

Thanks!
 
benschumacher said:
I'm a little disappointed to give up my 400+ days of uptime.
Click to expand...
Uptime is overrated. A box that has been up for 400+ days hasn't been updated in well over a year and probably hasn't seen any bugfixes and/or security fixes during that time either.

Of course we all know this quote from Linus Torvalds when he wanted to update his FTP server:
How do you power down this machine?
Click to expand...
but that's more about folklore than about sensible system management IMHO.
 
Additionally, if a box that fails to boot after 400+ days of uptime it can be a bit of a mystery as to how/when the breakage occurred.

Agreed - chasing uptime numbers "just because" is over-rated. So long as the machine stays up unless you tell it to reboot, the OS is doing its job just fine.
 
You must log in or register to reply here.
Back
Top