William Boehm
2012-04-27 01:50:07 UTC
I apologize in advance for the length of this email.
We currently have a system running omniORB-4.0.4 on Solaris (running
SunOs 5.8) and we want to upgrade to
omniORB-4.1.4, but we also want to support the older versions of our
application using omniORB-4.0.4.
I downloaded the following packages:
omniORB-4.1.4.tar.gz
omnipython-sun4_sosV_5.7.tar.gz (please note we used this version under
omniORB-4.0.4 as well)
We extracted the packages and then ran the make command defining the CC
and CXX to use cc(Sun C 5.6 Patch 117551-03 2004/11/23)
and CC(Sun C++ 5.5 2003/03/12) respectively. It appears that
omniORB-4.1.4 built successfully and the libraries are under the
build/lib directory. We did not run make install as we didn't want to
overwrite the original libraries in the /usr/local/lib
directory, so we changed our make files to point to the new libraries
under the build directory. We are able to rebuild our binaries
without an issues.
We then setup our runtime environment for our software on a different
server which has it's own copies of the libraries, and using the
old build and old omniORB-4.0.4 were able to start the system up with no
issues. We then move the new binaries and libraries over to
this environment and when we try to start the system, the naming
service(tnamerserv from Java 1.6) and our first module which is a
Java 1.6 CORBA module start fine, but the first module that has omniORB
built into it tries to start it fails with:
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/orbcore/orbOptions.cc
line: 153
info: findHandler(h.key()) == 0
/evaluate/ev_dev87a/shl/StartProcess.sh[69]: 19146 Abort(coredump)
The core shows the following:
fb74e364 _lwp_kill (6, 0, 0, fb72d954, ffffffff, 6) + 8
fb6c2910 abort (fdabd3ec, 1, fdabce1c, edbe0, fb7b3558, 0) + 110
fdaa5014 __1cH__CimplRdefault_terminate6F_v_ (fdabd3ec, fb7b5980, 1c00,
1793c,
0, fdaa5010) + 4
fdaa4e24 __1cH__CimplMex_terminate6F_v_ (fdabd5c0, 0, 0, fdabd5c0,
fdabcd10, 1)
+ 2c
fdaa5a30 _ex_throw_body (fdabd5c0, 0, ffbff3d8, 17374, fe9d2a00,
fdabd5c0) + 98
fdaa5978 __1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_
(fdabd5c0, fda
bd5c0, ff1d7a3c, fdabd5c0, 2c00, fdabd3f0) + 78
ff1d65f0 __1cEomniKassertFail6Fpkci2_v_ (ff2ec32c, bcc, 800, fdabd610,
10c154,
ff2e5d78) + c4
ff1e3e98 __1cEomniKorbOptionsPregisterHandler6Mrn0BHHandler__v_ (ddb80,
fb0b868
0, c00, fe830, fb0b4c3c, ff2e2688) + 48
faf93f64 __1cEomniZomni_corbaOrb_initialiser2t5B6M_v_ (fb0b8728, 1f74,
11db28,
fdaa655c, fb0b1a48, 1c00) + 50
faf93ef4 __SLIP.INIT_O (0, 256c, faf93eb0, fb0b1a48, 11db6c, 2400) + 24
faf9677c __1cU__STATIC_CONSTRUCTOR6F_v_ (0, fb4ea700, ed3dc, fdaa6db0,
fb4ea6c0
, fffbd240) + 74
fb04dae8 _init (0, 1, fe9d2a00, ff3fa984, 1, ff3fd468) + 118
ff3c4bf0 call_init (fed819e0, 1, 1, fb04d9d0, 80, febb1928) + 128
ff3c3f64 setup (0, 46, 0, 21401, 0, 2) + 18f8
ff3d5f10 _setup (ffffffff, 0, ffbff41c, 2, ffffffff, ffffffff) + 418
ff3b5698 _rt_boot (0, 0, 0, 0, 0, 0) + 88
00000000 ???????? (0, 0, 0, 0, 0, 0)
A couple of other things of note are that we start our module passing in
the location of our module INI file
followed by -ORBInitRef
NameService=corbaloc::nameofmachine:23826/NameService, we have the
following
in our omni.ini file using the OMNIORB_CONFIG variable:
dumpConfiguration=1
maxGIOPConnectionPerServer=100
giopMaxMsgSize=524288000
traceExceptions=0
strictIIOP=0
scanGranularity=15
outConScanPeriod=30
inConScanPeriod=30
abortOnInternalError=0
maxGIOPVersion=1.0
Lastly from the looks of our logs (The first thing our main method does
is print to the log) it doesn't even appear to get to
our code.
Can you please help?
Bill
Bill Boehm
8440 Eli Whitney Dr. Ste 200
Columbia, MD 21046
Phone 410-953-8407
------------------------------------------------------------------------
------
"The information contained in this email message may be privileged
and/or confidential and protected from disclosure under applicable law.
It is intended only for the individual to whom or entity to which it is
addressed as shown at the beginning of the message. If the reader of
this message is not the intended recipient, or if the employee or agent
responsible for delivering the message is not an employee or agent of
the intended recipient, you are hereby notified that any review,
dissemination, distribution, use, or copying of this message is strictly
prohibited. If you have received this message in error, please notify us
immediately by return email and permanently delete this message and your
reply to the extent it includes this message. Any views or opinions
presented in this message or attachments are those of the author and do
not necessarily represent those of the Company. All emails and
attachments sent and received are subject to monitoring, reading and
archival by the Company."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20120426/bd5eb04d/attachment.htm
We currently have a system running omniORB-4.0.4 on Solaris (running
SunOs 5.8) and we want to upgrade to
omniORB-4.1.4, but we also want to support the older versions of our
application using omniORB-4.0.4.
I downloaded the following packages:
omniORB-4.1.4.tar.gz
omnipython-sun4_sosV_5.7.tar.gz (please note we used this version under
omniORB-4.0.4 as well)
We extracted the packages and then ran the make command defining the CC
and CXX to use cc(Sun C 5.6 Patch 117551-03 2004/11/23)
and CC(Sun C++ 5.5 2003/03/12) respectively. It appears that
omniORB-4.1.4 built successfully and the libraries are under the
build/lib directory. We did not run make install as we didn't want to
overwrite the original libraries in the /usr/local/lib
directory, so we changed our make files to point to the new libraries
under the build directory. We are able to rebuild our binaries
without an issues.
We then setup our runtime environment for our software on a different
server which has it's own copies of the libraries, and using the
old build and old omniORB-4.0.4 were able to start the system up with no
issues. We then move the new binaries and libraries over to
this environment and when we try to start the system, the naming
service(tnamerserv from Java 1.6) and our first module which is a
Java 1.6 CORBA module start fine, but the first module that has omniORB
built into it tries to start it fails with:
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/orbcore/orbOptions.cc
line: 153
info: findHandler(h.key()) == 0
/evaluate/ev_dev87a/shl/StartProcess.sh[69]: 19146 Abort(coredump)
The core shows the following:
fb74e364 _lwp_kill (6, 0, 0, fb72d954, ffffffff, 6) + 8
fb6c2910 abort (fdabd3ec, 1, fdabce1c, edbe0, fb7b3558, 0) + 110
fdaa5014 __1cH__CimplRdefault_terminate6F_v_ (fdabd3ec, fb7b5980, 1c00,
1793c,
0, fdaa5010) + 4
fdaa4e24 __1cH__CimplMex_terminate6F_v_ (fdabd5c0, 0, 0, fdabd5c0,
fdabcd10, 1)
+ 2c
fdaa5a30 _ex_throw_body (fdabd5c0, 0, ffbff3d8, 17374, fe9d2a00,
fdabd5c0) + 98
fdaa5978 __1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_
(fdabd5c0, fda
bd5c0, ff1d7a3c, fdabd5c0, 2c00, fdabd3f0) + 78
ff1d65f0 __1cEomniKassertFail6Fpkci2_v_ (ff2ec32c, bcc, 800, fdabd610,
10c154,
ff2e5d78) + c4
ff1e3e98 __1cEomniKorbOptionsPregisterHandler6Mrn0BHHandler__v_ (ddb80,
fb0b868
0, c00, fe830, fb0b4c3c, ff2e2688) + 48
faf93f64 __1cEomniZomni_corbaOrb_initialiser2t5B6M_v_ (fb0b8728, 1f74,
11db28,
fdaa655c, fb0b1a48, 1c00) + 50
faf93ef4 __SLIP.INIT_O (0, 256c, faf93eb0, fb0b1a48, 11db6c, 2400) + 24
faf9677c __1cU__STATIC_CONSTRUCTOR6F_v_ (0, fb4ea700, ed3dc, fdaa6db0,
fb4ea6c0
, fffbd240) + 74
fb04dae8 _init (0, 1, fe9d2a00, ff3fa984, 1, ff3fd468) + 118
ff3c4bf0 call_init (fed819e0, 1, 1, fb04d9d0, 80, febb1928) + 128
ff3c3f64 setup (0, 46, 0, 21401, 0, 2) + 18f8
ff3d5f10 _setup (ffffffff, 0, ffbff41c, 2, ffffffff, ffffffff) + 418
ff3b5698 _rt_boot (0, 0, 0, 0, 0, 0) + 88
00000000 ???????? (0, 0, 0, 0, 0, 0)
A couple of other things of note are that we start our module passing in
the location of our module INI file
followed by -ORBInitRef
NameService=corbaloc::nameofmachine:23826/NameService, we have the
following
in our omni.ini file using the OMNIORB_CONFIG variable:
dumpConfiguration=1
maxGIOPConnectionPerServer=100
giopMaxMsgSize=524288000
traceExceptions=0
strictIIOP=0
scanGranularity=15
outConScanPeriod=30
inConScanPeriod=30
abortOnInternalError=0
maxGIOPVersion=1.0
Lastly from the looks of our logs (The first thing our main method does
is print to the log) it doesn't even appear to get to
our code.
Can you please help?
Bill
Bill Boehm
8440 Eli Whitney Dr. Ste 200
Columbia, MD 21046
Phone 410-953-8407
------------------------------------------------------------------------
------
"The information contained in this email message may be privileged
and/or confidential and protected from disclosure under applicable law.
It is intended only for the individual to whom or entity to which it is
addressed as shown at the beginning of the message. If the reader of
this message is not the intended recipient, or if the employee or agent
responsible for delivering the message is not an employee or agent of
the intended recipient, you are hereby notified that any review,
dissemination, distribution, use, or copying of this message is strictly
prohibited. If you have received this message in error, please notify us
immediately by return email and permanently delete this message and your
reply to the extent it includes this message. Any views or opinions
presented in this message or attachments are those of the author and do
not necessarily represent those of the Company. All emails and
attachments sent and received are subject to monitoring, reading and
archival by the Company."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20120426/bd5eb04d/attachment.htm