[omniORB] Py_ServantLocator Core Dump

[Duncan Grisby]

On Friday 15 September, Gary Pennington wrote:

> I have some code which implements the Evictor pattern using Servant
> Locators (lifted from Henning/Vinoski and adapted to Python). The
> application is multi-threaded and I am using multiple POA and
> POAManagers to try and optimize throughput on SMP boxes.

It doesn't have anything to do with your core dump, but do you realise
that Python has a global interpreter lock?  Only one thread can be
executing Python code at a time -- every few bytecode instructions,
the interpreter lock is unlocked to switch to a different thread. This
means that when your server is running Python code, only one processor
will be running at a time. Other processors will still be able to do
other omniORB tasks, like the early stages of operation dispatch, so
you will still get some advantages from the multiple processors.

> When the system is under heavy load, i.e. load testing, I get a core
> dump in the server process. The core indicates that the problem arises
> in :-
> 
> -----------------  lwp# 12 / thread# 162  --------------------
>  ff0afa5c
> __0fRPy_ServantLocatorKpostinvokeRC65OPortableServerIObjectIdP65OPorta
> bleServerDPOAPCcPvP65OPortableServerLServantBase (36a930, fe00fa3c,
> 33fbe0, fe00
> fbe4, a087c, 4ba610) + 40

I don't know what's going on here. There is very little code in
Py_ServantLocator::postinvoke() which isn't calls into other
functions. If anything was invalid, I would expect it to coredump in
some sub-function. Can you build a version of omniORBpy with debugging
information so we can see exactly where the error happens?

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --