Re: [cx-oracle-users] segmentation violations

[Anthony T. <ant...@gm...>]

Hi Fred,

You seem to be experiencing a sort of memory corruption perhaps due to an
overwrite somewhere. If you were using threads I would have immediately
told you that you need to ensure threaded mode is enabled -- but I don't
see multiple threads in use. You may wish to enable it anyway to see if you
get consistent results, but that shouldn't be a problem.

I have seen similar, highly intermittent, segfaults inside
OCIServerAttach() myself, but only when using threads -- and they don't
terminate in the same place.

You could try using a session pool (cx_Oracle.SessionPool) with or without
DRCP to see if that makes things happier. Not sure how many connections you
are generally creating but if you are creating a few this would improve
performance anyway!

You can try enabling diagnostics for Oracle and seeing if interesting
information shows up. You can also see if you get consistent backtraces.

All of that said, I don't have this problem! Of course I'm not running the
exact configuration you have. Depending on what you get from backtraces and
diagnostics you can log a support request and see if they can help you.

Anthony

On Tue, Oct 25, 2016 at 10:38 AM, Fred Yankowski <fc...@im...> wrote:

> 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 <http://www.web2py.con>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
>
> ------------------------------
>
> 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
>
>
> ------------------------------------------------------------
> ------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>