| | | | | Browse by category |
When destroying connections, Linux coredumps on multithreaded builds with the Oracle8 805 client and the Oracle 805, 815, and 817 server. The problem occurs for multithreaded builds built with or without the Rogue Wave Standard C++ Library or the native Standard Library. You may also see the error "kgepop: no error frame to pop to...", usually written to the standard error stream.
Cause
Multithreaded builds on Linux are not supported for the Oracle 8 805 client.
This is an Oracle defect seen only with Oracle 8 805 clients on Linux. The server corrupts memory and results in coredumps on multithreaded builds. The problem may have been fixed in some patches to the server (see the Oracle patch-bug information below), but Source Pro DB has not been certified on these patches.
This usually intermittent problem is most likely attributed to running POSIX threads with the Oracle 8 805 client. The error "kgepop: no error frame to pop to..." is usually written to the standard error stream when this problem occurs.
Related Oracle Bugs:
Fixes in the 8.0.5.0.2 server for Solaris:
[709536] If a multithreaded program started many threads executing
SQL statements at the same time, SQL memory initialization
could run concurrently, causing an access violation.
[758377] When using a multithreaded OCI application, initializing in
OBJECT MODE is not thread-safe and may cause a process dump.
Bug fixes for the 8.0.X server:
8061N [BUG:781204] Thread-safe client may leak memory on connect/disconnect
8061 [BUG:908749] OCI object cache not initialized as thread-safe
8061 [BUG:944913] Dump from multithreaded client
8061 [BUG:988984] Dump possible from multithreaded client (Rogue Wave #25841)
Action
There are three approaches to solving this problem:
1. Use only single-threaded buildtypes on Linux with the Oracle8 805 client.
2. Upgrade to the Oracle8 817 client if multithreaded builds are necessary.
3. If you must use the Oracle8 805 client with multithreaded builds, a possible workaround is to wrap all OCI calls in a mutex to disable the concurrent usage of the Oracle libraries from a single application. Please note that this workaround is only a suggestion, and has not been tested.
Why won't the InfoBrowser contents update in response to selection changes in ClassView or FileView?
