[omniORB] Question about seg faults in servants.

[JohnD.Heintz]

Anyone have a response to this?  It seems weird...

John


On Monday 13 August 2001 11:54, joshuar wrote:
> 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
> <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?
> >>
> >> From 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

----------------------------------------
Content-Type: text/plain; charset=3D"us-ascii"; name=3D"Attachment: 1"
Content-Transfer-Encoding: 7bit
Content-Description:=20
----------------------------------------

----------------------------------------
Content-Type: application/octet-stream; charset=3D"us-ascii"; name=3D"bre=
aker.c"
Content-Transfer-Encoding: quoted-printable
Content-Description:=20
----------------------------------------

----------------------------------------
Content-Type: text/plain; charset=3D"iso-8859-1"; name=3D"Attachment: 3"
Content-Transfer-Encoding: quoted-printable
Content-Description:=20
----------------------------------------

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m