[omniORB] Question about seg faults in servants.
joshuar
joshuar@isogen.com
Mon, 13 Aug 2001 11:54:05 -0500
--Apple-Mail-691204268-3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
format=flowed;
charset=iso-8859-1
I have attached the breaker.c file for the python extension module that=20=
we used to exhibit this behaviour.
We only see this behaviour on our win2k machine ( I have the compiled=20
breaker.dll if you are interested --about 40k-- )
Here are the alterations that we have made to the echo example
$ diff examples/echo/echo_srv.py examples-old/echo/echo_srv.py
4,5d3
< import thread
< import breaker
18,23d16
< def breakMe(self):
< breaker.callVoid()
<
< def breakMeSeperateThread(self):
< thread.start_new_thread(breaker.callVoid, ())
<
$ diff examples/echo/echo.idl examples-old/echo/echo.idl
4,5
< void breakMe();
< void breakMeSeperateThread();
We have compiled the module for linux (2.4.x) as well and here are the=20=
wonky results.
In all cases we ran the echo_clt.py interactively then called the=20
appropriate methods.
Linux:
In either method call the server segfaults
For breakMe() we get an CORBA.UNKNOWN on the client.
For breakMeSeperateThread() there is no output on the client (finishes=20=
before thread segfaults server)
Windows:
a call to breakMeSeperateThread() causes a windows Application Error=20
(i.e. segfault) in the server and windows kills the process, again no=20
output on client (no prob)
but ...
a call to breakMe() causes a CORBA.UNKNOWN to be raised, but the server=20=
keeps running and is still usable.
subsequent calls to echoString() succeed just fine.
Let me know if you want the dll or the VC++ workspace etc.
Oh right, in all cases we are using python 2.1.1,
and omniORB 3.0.4 omniORBpy 1.4 both out of cvs
-- Joshua
<Attachment missing>
On Monday, August 13, 2001, at 09:23 AM, Duncan Grisby wrote:
> On Friday 10 August, John D. Heintz wrote:
>
>> How is omniORB handling seg faults in servants?
>>
>> =46rom omniORBpy the behavior we are seeing it that the thread the
>> request comes in on jumps immediately out of our code and a
>> CORBA.UNKNOWN is raised to the client.
>
> That's interesting! omniORB doesn't do anything to trap seg faults,
> so I would have expected it to just dump core. Perhaps some other
> library you are using has installed a signal handler to catch sigsegv?
>
> What platform and version of Python are you using?
>
> You might get somewhere with WAD:
>
> http://systems.cs.uchicago.edu/wad/
>
> I've never used it, so I can't tell you anything about it.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --
>
>
Joshua Reynolds | Untitled
1016 La Posada |Suite 240|Austin, TX=A0 78752
=A0=A0=A0=A0=A0 T 512-380-0347|=A0F 512-380-0429=A0|joshuar@isogen.com
w w w . d a t a c h a n n e l . c o m/w w w . i s o g e n . c o m
--Apple-Mail-691204268-3
Content-Type: multipart/mixed;
boundary=Apple-Mail-1628246389-4
--Apple-Mail-1628246389-4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii;
format=flowed
I have attached the breaker.c file for the python extension module that
we used to exhibit this behaviour.
We only see this behaviour on our win2k machine ( I have the compiled
breaker.dll if you are interested --about 40k-- )
Here are the alterations that we have made to the echo example
$ diff examples/echo/echo_srv.py examples-old/echo/echo_srv.py
4,5d3
< import thread
< import breaker
18,23d16
< def breakMe(self):
< breaker.callVoid()
<
< def breakMeSeperateThread(self):
< thread.start_new_thread(breaker.callVoid, ())
<
$ diff examples/echo/echo.idl examples-old/echo/echo.idl
4,5
< void breakMe();
< void breakMeSeperateThread();
We have compiled the module for linux (2.4.x) as well and here are the
wonky results.
In all cases we ran the echo_clt.py interactively then called the
appropriate methods.
Linux:
In either method call the server segfaults
For breakMe() we get an CORBA.UNKNOWN on the client.
For breakMeSeperateThread() there is no output on the client (finishes
before thread segfaults server)
Windows:
a call to breakMeSeperateThread() causes a windows Application Error
(i.e. segfault) in the server and windows kills the process, again no
output on client (no prob)
but ...
a call to breakMe() causes a CORBA.UNKNOWN to be raised, but the server
keeps running and is still usable.
subsequent calls to echoString() succeed just fine.
Let me know if you want the dll or the VC++ workspace etc.
Oh right, in all cases we are using python 2.1.1,
and omniORB 3.0.4 omniORBpy 1.4 both out of cvs
-- Joshua
--Apple-Mail-1628246389-4
Content-Disposition: attachment;
filename="breaker.c"
Content-Type: application/octet-stream;
name="breaker.c";
x-unix-mode=0644
Content-Transfer-Encoding: quoted-printable
=0D=0A#include=20"Python.h"=0D=0A=0D=0Avoid=20initbreaker(void);=20/*=20=
Forward=20*/=0D=0Astatic=20void=20theKiller(void=20(*foo)=20());=0D=0A/*=20=
A=20static=20module=20*/=0D=0A=0D=0A/*=20'self'=20is=20not=20used=20*/=0D=
=0A=0D=0Astatic=20void=0D=0AtheKiller(void=20(*foo)())=0D=0A{=0D=0A=09=
(*foo)();=0D=0A};=0D=0A=0D=0Astatic=20PyObject=20*=0D=0A=
breaker_incrNull(PyObject=20*self,=20PyObject*=20args)=0D=0A{=0D=0A=09=
PyObject=20*nully=20=3D=20NULL;=0D=0A=09if=20(!PyArg_ParseTuple(args,=20=
""))=0D=0A=09=09return=20NULL;=0D=0A=0D=0A=09Py_INCREF(nully);=0D=0A=09=
return=20nully;=0D=0A};=0D=0A=0D=0Astatic=20PyObject=20*=0D=0A=
breaker_callVoid(PyObject=20*self,=20PyObject*=20args)=0D=0A{=0D=0A=09=
void=20*=20kHelper=20=3D=20NULL;=0D=0A=09if=20(!PyArg_ParseTuple(args,=20=
""))=0D=0A=09=09return=20NULL;=0D=0A=0D=0A=09theKiller((void(*)(void))=20=
kHelper);=0D=0A=09=0D=0A=09return=20self;=0D=0A=0D=0A}=0D=0A=0D=0Astatic=20=
PyMethodDef=20breaker_methods[]=20=3D=20{=0D=0A=09{"callVoid",=09=
breaker_callVoid,=09METH_VARARGS},=0D=0A=09{"incrNull",=09=09=
breaker_incrNull,=09METH_VARARGS},=0D=0A=09{NULL,=09=09NULL}=09=09/*=20=
sentinel=20*/=0D=0A};=0D=0A=0D=0Avoid=0D=0Ainitbreaker(void)=0D=0A{=0D=0A=
=09Py_InitModule("breaker",=20breaker_methods);=0D=0A}=0D=0A=
--Apple-Mail-1628246389-4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1;
format=flowed
On Monday, August 13, 2001, at 09:23 AM, Duncan Grisby wrote:
> On Friday 10 August, John D. Heintz wrote:
>
>> How is omniORB handling seg faults in servants?
>>
>> =46rom omniORBpy the behavior we are seeing it that the thread the
>> request comes in on jumps immediately out of our code and a
>> CORBA.UNKNOWN is raised to the client.
>
> That's interesting! omniORB doesn't do anything to trap seg faults,
> so I would have expected it to just dump core. Perhaps some other
> library you are using has installed a signal handler to catch sigsegv?
>
> What platform and version of Python are you using?
>
> You might get somewhere with WAD:
>
> http://systems.cs.uchicago.edu/wad/
>
> I've never used it, so I can't tell you anything about it.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --
>
>
Joshua Reynolds | Untitled
1016 La Posada |Suite 240|Austin, TX=A0 78752
=A0=A0=A0=A0=A0 T 512-380-0347|=A0F 512-380-0429=A0|joshuar@isogen.com
w w w . d a t a c h a n n e l . c o m/w w w . i s o g e n . c o m
--Apple-Mail-1628246389-4--
--Apple-Mail-691204268-3--