Re: [cx-oracle-users] segmentation violations
Brought to you by:
atuining
From: Fred Y. <fc...@im...> - 2016-10-25 16:38:52
|
I posted the code at https://gist.github.com/fredcy/ebb24602ef9cd94ec5e349affa573cd8 The test function is practically the simplest test case I could think of. When it fails it’s in the call to cx_Oracle.connect . It does not always fail. When it does fail the typical pattern is that the first call to connect works and it’s able to run the query and print the results; but the second connect then fails. But other times it runs a bunch of connections successively and they all work. I added some code to dump the context and enable faulthandler. Oddly, enabling those options affects the results! 1. python gist/testoracle.py --count 20 hangs on second connect; has to be killed from elsewhere. 2. python gist/testoracle.py --count 20 --fault runs all 20 connections without problem. 3. python gist/testoracle.py --count 20 --fault --info fails on second connect and quits. 4. python gist/testoracle.py --count 20 --info runs all 20 connections without problem. The --fault and --info arguments cause conditional imports. I wonder if some side effect of those imports is changing the context in some subtle way that hides the problem in some cases and shows it in others. Maybe something concerning memory placement of the cx_Oracle code? Also, when I modify my driver script in ways that don’t directly affect the cx_Oracle code it can cause changes in how it behaves. Here is the result of running with --info : platform: Linux-3.10.10-imsa01-MOD-RHVM-SMP.cos64-x86_64-with-redhat-6.8-Santiago architecture: ('64bit', 'ELF') python_build: ('default', 'Jul 22 2014 16:14:39') python_compiler: GCC 4.4.7 20120313 (Red Hat 4.4.7-4) python_version: 2.7.8 libc_ver: ('glibc', '2.2.5') uname: ('Linux', 'app.devnet.imsa.edu', '3.10.10-imsa01-MOD-RHVM-SMP.cos64', '#4 SMP Thu Sep 5 16:18:19 CDT 2013', 'x86_64', 'x86_64') Background The problem arose last Friday afternoon. I had within the hour changed our Apache configuration to use a stronger SSL/TLS configuration. I keep /etc under source code control and had baselined it earlier that day so I’m quite sure about what changes I made. Our stack is Web2py 2.14.6 ( www.web2py.co m) on Apache (Apache/2.2.15 (Unix) mod_wsgi/3.4 Python/2.7.8 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips configured). I also tweaked Apache to discard proxy headers in the client request. Not long after those changes I started seeing errors from cron jobs that use curl to run requests against the above service. By instrumenting the python code I found that the connection to Oracle was sometimes failing. On Monday I temporarily reverted those changes and restarted Apache. The connection problems continued to happen. So I then created a standalone python script (gist link above) to test the Oracle connections. I ran it using the same python virtualenv that the web service above uses, and it failed. I then tried the same from a development server that runs the same stack but which was not updated with the SSL changes. And it shows the same problem. So I’m baffled, since the problem seemed to arise right after the SSL/TLS config changes but the same problem happens on a similar unmodified system. I then built a new virtualenv on the dev server with just the lastest version of cx_Oracle (and faulthandler). And that fails the same way. It’s possible that the Apache restart on Friday picked up some system change that had been lurking, but I’ve looked hard at prior configuration changes and can’t see anything that could matter. So I’m stumped. -- Fred Yankowski fc...@im... +1-630-907-5019 ----- Original Message ----- > Hi Fred, > Are you able to post the code that is causing the problem? And of course, the > age old question: what did you change? :-) That may help diagnose why this > has turned up now -- and potentially help resolve the problem for others as > well. > Anthony |