[omniORB]:Bus Error in application ported from ORBIX2000 toomniORB4.0.5(more inputs)

Fri Feb 11 09:14:12 GMT 2005

Mahesh,

Perhaps you are calling code that is not thread-safe from servant code (code that is executed in response to a CORBA method invokation).

Each time your methods are called by the ORB, they may be executing in a different thread. This can cause all sorts of trouble. For example, you should always unlock a mutex in the same thread that locked it. If the mutex locking is done in library code, it can be hard to spot what you're doing wrong.

You could try using omniORB's 'main thread policy' to avoid this problem - it enables you to run all servant code in the main thread. It's worked for me in the past.

best of luck,

-Alex Tingle

-- 
:: alex tingle
:: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net  +44-7901-552763 

On Fri, 11 Feb 2005 12:37:16 +0530
Mahesh Bhatt <mahesh_bhatt at credence.com> wrote:

> 
> Hi,
> 
> 
> More inputs for my application bus error:
> 
> My application generate bus error in the function call "OI_make_top_level(..)".
> This function is part of third party GUI toolkit (libOI.so.5).
> 
> One strange thing, if I comment one statement "glyph->set_pixmap(...);"
> from source code then my application is working fine.
> 
> "glyph" is a rectangular object which can containing an X Window System Pixmap image.
> This is used for display some image in the icon.
> 
> Following is output of where in dbx for my application:
> 
> (dbx) where
>   [1] malloc(0x30, 0xc392b0, 0xdcc3f0, 0x78, 0x32, 0xfeb848b8), at 0x47474c
>   [2] operator new(0x30, 0x1, 0x13950, 0xfea35778, 0xfe849ad8, 0xc84e68), at 0xfe8361ac
>   [3] OI_attr_misc::clone(0xc5e660, 0xc78800, 0xffffc000, 0xc5e660, 0xc387b8, 0x4), at 0x
>   [4] OI_attr_misc::set_border_width(0xc5e660, 0xc23c00, 0x1, 0xc5e660, 0x430000, 0xfeb84
>   [5] OI_d_tech::set_abs_bdr_width(0xdb45a0, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfea10b20
>   [6] OI_d_tech::re_configure(0x32, 0x78, 0x0, 0xfeb848b8, 0x10, 0xfeb848b8), at 0xfea179
>   [7] OI_d_tech::new_bdr_width(0xdb45a0, 0x1, 0xdb45a0, 0xfeb848b8, 0xdb45a0, 0xfff), at
>   [8] OI_box::construct(0x20000000, 0x78, 0x938c58, 0xfeb848b8, 0xfe81a000, 0xdb45a0), at
>   [9] OI_box::OI_box(0xdb45a0, 0xc392b0, 0xdcc3f0, 0x78, 0x32, 0xfeb848b8), at 0xfe9e6c30
>   [10] OI_dialog_box::OI_dialog_box(0xdb45a0, 0xdcc3f0, 0x78, 0x32, 0xffffffff, 0x0), at
>   [11] oi_create_dialog_box(0xdcc3f0, 0xdb45a0, 0xdb45a0, 0xffffffff, 0x0, 0xfeb848b8), a
>   [12] OI_d_tech::new_children(0xdcc3f9, 0xdcc3f0, 0xfeb848b8, 0x1, 0x10000000, 0xdcc3fa)
>   [13] OI_make_top_level(0xfebb1cd4, 0x0, 0xfebb2ba0, 0xfeb848b8, 0x0, 0x16d), at 0xfeaae
> =>[14] InitSearchbox(parentWin = 13082112), line 93 in "searchbox.C"
>   [15] main(argc = 1, argv = 4290700572), line 295 in "xlayout.C"
> (dbx)
> 
> 
> (dbx) where -l
>   [1] myApp:malloc(0x30, 0xc392b0, 0xdcc3f0, 0x78, 0x32, 0xfeb848b8), at 0x47474c
>   [2] libCrun.so.1:operator new(0x30, 0x1, 0x13950, 0xfea35778, 0xfe849ad8, 0xc84e68), at 0xfe8361ac
>   [3] libOI.so.5:OI_attr_misc::clone(0xc5e660, 0xc78800, 0xffffc000, 0xc5e660, 0xc387b8, 0x4), at 0xfe9df874
>   [4] libOI.so.5:OI_attr_misc::set_border_width(0xc5e660, 0xc23c00, 0x1, 0xc5e660, 0x430000, 0xfeb848b8), at
> 0xfe9dfd78
>   [5] libOI.so.5:OI_d_tech::set_abs_bdr_width(0xdb45a0, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfea10b20
>   [6] libOI.so.5:OI_d_tech::re_configure(0x32, 0x78, 0x0, 0xfeb848b8, 0x10, 0xfeb848b8), at 0xfea1797c
>   [7] libOI.so.5:OI_d_tech::new_bdr_width(0xdb45a0, 0x1, 0xdb45a0, 0xfeb848b8, 0xdb45a0, 0xfff), at 0xfea2aa18
>   [8] libOI.so.5:OI_box::construct(0x20000000, 0x78, 0x938c58, 0xfeb848b8, 0xfe81a000, 0xdb45a0), at 0xfe9e7934
>   [9] libOI.so.5:OI_box::OI_box(0xdb45a0, 0xc392b0, 0xdcc3f0, 0x78, 0x32, 0xfeb848b8), at 0xfe9e6c30
>   [10] libOI.so.5:OI_dialog_box::OI_dialog_box(0xdb45a0, 0xdcc3f0, 0x78, 0x32, 0xffffffff, 0x0), at 0xfea35778
>   [11] libOI.so.5:oi_create_dialog_box(0xdcc3f0, 0xdb45a0, 0xdb45a0, 0xffffffff, 0x0, 0xfeb848b8), at 0xfea34d84
>   [12] libOI.so.5:OI_d_tech::new_children(0xdcc3f9, 0xdcc3f0, 0xfeb848b8, 0x1, 0x10000000, 0xdcc3fa), at
> 0xfea2bf10
>   [13] libOI.so.5:OI_make_top_level(0xfebb1cd4, 0x0, 0xfebb2ba0, 0xfeb848b8, 0x0, 0x16d), at 0xfeaae66c
> =>[14] myApp:InitSearchbox(parentWin = 13082112), line 93 in "searchbox.C"
>   [15] myApp:main(argc = 1, argv = 4290700572), line 295 in "xlayout.C"
> (dbx)
> 
> Any suggestion or hint.
> 
> Thanks,
> Mahesh
> 
> 
> 
> 
> >
> > Date: Thu, 10 Feb 2005 13:38:22 +0100
> > From: "Wernke zur Borg" <wzb at anitesystems.de>
> > Subject: RE: [omniORB]:Bus Error in application ported from ORBIX2000
> >         toomniORB4.0.5
> > To: <omniorb-list at omniorb-support.com>
> > Message-ID: <200502101238.j1ACcM402641 at maia.anitesystems.de>
> > Content-Type: text/plain; charset="us-ascii"
> >
> >
> > Looks like a heap corruption... I would first enter 'where' to the dbx
> > prompt. The dynamic dependencies are not as interesting as a stack trace.
> >
> > Wernke
> >
> >   _____
> >
> > From: omniorb-list-bounces at omniorb-support.com
> > [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Mahesh Bhatt
> > Sent: 10 February 2005 13:01
> > To: omniorb-list at omniorb-support.com
> > Subject: [omniORB]:Bus Error in application ported from ORBIX2000
> > toomniORB4.0.5
> >
> >
> > Hi,
> >
> > I am porting my GUI based application (myApp) from Orbix2000 to
> > OmniORB4.0.5 on Sun Solaris 8.
> >
> > After porting application to omniORB4.0.5, my application is
> > producing bus error. Following is the runtime output:
> >
> >  <snip>
> >
> > Any suggestions, what could be the cause of bus error while using omniORB?
> >
> > Thanks in advance for your help!
> > Mahesh
> >
> 

-- 
:: alex tingle
:: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net  +44-7901-552763 

-- 
:: alex tingle
:: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net  +44-7901-552763 