New submission from Chinh Nguyen:

I'm using ctypes to access the PAM library to change a user's password. That 
is, using the function pam_chauthtok. This is occurring inside a python celery 
worker in FreeBSD. This will work the first time, the second time generates a 
segfault and crashes the worker.

On attaching gdb to the worker process, I observe the following:
* Crash occurs in function login_setcryptfmt
* Setting a breakpoint there, I see the following after the first successful 
password change "warning: Temporarily disabling breakpoints for unloaded shared 
library "/lib/libcrypt.so.5"
* When there is segfault on the second password change, the location of the 
segfault cannot be disassemble
* It doesn't look like libcrypt is a direct dependency of libpam.

So it looks like what is happening is this:
* libcrypt is loaded (by python/system?) to invoke some password-related 
functions, it is then unloaded (by python/system?)
* When the same function is invoked again, somehow libcrypt does not get 
loaded. This results in a function call to the same function address which is 
now invalid.

My current work-around is to include libcrypto explicitly by binding to it 
though I don't use it directly. For example, libcrypt = 
CDLL(find_library("crypt")).

Other notes:
* This does not occur if I launch celery worker all running in the same process 
via the celery "green threads" module eventlet
* This only happens if the celery worker is a python child process. I don't 
know how celery spawns child processes.

----------
components: ctypes
messages: 291798
nosy: Chinh Nguyen
priority: normal
severity: normal
status: open
title: Automatic Unload of Dynamic Library Cause Segfault
type: crash
versions: Python 2.7

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30089>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to