[omniORB] Using NJAMD with Omniorb
Sai-Lai Lo
S.Lo@uk.research.att.com
19 Jul 2000 15:13:16 +0100
Robert,
Before I posted my previous message, I've checked that with the echo
examples and they work fine *AFTER* I reorder -ltcpwrapGK to come before
-lomnithread. In fact, if you try NJAMD with the thread examples, they all
work fine.
You may want to try out this change to <top>/mk/unix.mk, which just reorder
the -l flags to the order I described. And then relink and test the
examples.
Sai-Lai
Index: unix.mk
===================================================================
diff -c oldomni/mk/unix.mk omni/mk/unix.mk
*** unix.mk 2000/02/22 17:25:20 1.1.8.2
--- unix.mk 2000/07/19 14:10:31
***************
*** 150,164 ****
OMNIORB_CPPFLAGS = -D__OMNIORB3__ -I$(CORBA_STUB_DIR) $(OMNITHREAD_CPPFLAGS)
OMNIORB_LIB = $(patsubst %,$(LibSearchPattern),omniORB3) \
! $(patsubst %,$(LibSearchPattern),omniDynamic3) \
! $(OMNITHREAD_LIB) $(SOCKET_LIB)
! OMNIORB_LIB_NODYN = $(patsubst %,$(LibSearchPattern),omniORB3) \
! $(OMNITHREAD_LIB) $(SOCKET_LIB)
!
! OMNIORB_LIB_NODYN_DEPEND = $(omniORB_lib_depend) $(OMNITHREAD_LIB_DEPEND)
! OMNIORB_LIB_DEPEND = $(omniORB_lib_depend) $(OMNITHREAD_LIB_DEPEND) \
! $(omniDynamic_lib_depend)
OMNIORB_STATIC_STUB_OBJS = \
$(CORBA_INTERFACES:%=$(CORBA_STUB_DIR)/%SK.o)
OMNIORB_STATIC_STUB_SRCS = \
--- 150,161 ----
OMNIORB_CPPFLAGS = -D__OMNIORB3__ -I$(CORBA_STUB_DIR) $(OMNITHREAD_CPPFLAGS)
OMNIORB_LIB = $(patsubst %,$(LibSearchPattern),omniORB3) \
! $(patsubst %,$(LibSearchPattern),omniDynamic3)
! OMNIORB_LIB_NODYN = $(patsubst %,$(LibSearchPattern),omniORB3)
+ OMNIORB_LIB_NODYN_DEPEND = $(omniORB_lib_depend)
+ OMNIORB_LIB_DEPEND = $(omniORB_lib_depend) $(omniDynamic_lib_depend)
+
OMNIORB_STATIC_STUB_OBJS = \
$(CORBA_INTERFACES:%=$(CORBA_STUB_DIR)/%SK.o)
OMNIORB_STATIC_STUB_SRCS = \
***************
*** 194,199 ****
--- 191,204 ----
OMNIORB_LIB_NODYN += $($(omniORBGatekeeperImplementation)_LIB)
OMNIORB_LIB_DEPEND += $($(omniORBGatekeeperImplementation)_LIB_DEPEND)
OMNIORB_LIB_NODYN_DEPEND += $($(omniORBGatekeeperImplementation)_LIB_DEPEND)
+
+ # thread libraries required by omniORB. Make sure this is the last in
+ # the list of omniORB related libraries
+
+ OMNIORB_LIB += $(OMNITHREAD_LIB) $(SOCKET_LIB)
+ OMNIORB_LIB_NODYN += $(OMNITHREAD_LIB) $(SOCKET_LIB)
+ OMNIORB_LIB_DEPEND += $(OMNITHREAD_LIB_DEPEND)
+ OMNIORB_LIB_NODYN_DEPEND += $(OMNITHREAD_LIB_DEPEND)
# LifeCycle stuff
>>>>> Robert Stent writes:
> I agree with you that the demonstration program will now function,
> however, my original source still experiences the same symptom. I am
> sure we just pushed off the inevitable. I will try to pare down what I
> have to something that is demonstrable. I am also willing to bet if you
> have any real object code of your own that you attempt to leak check you
> will see the same problem.
> Sai-Lai Lo wrote:
>> Mike,
>>
>> omnithread is just a small C++ wrapper class that is implemented on top of
>> pthread. I can reproduce your segv.
>>
>> I've done some investigation. The segv can be avoided by reordering the
>> libraries when they are linked. Specifically, if one links -ltcpwrapGK
>> before -lomnithread and -lpthread, the program runs fine with libnjamd.so
>> preloaded.
>>
>> In other words, do something like this instead with your example:
>>
>> cat > bad.cpp << EOF
>> #include <iostream.h>
>> #include <omniORB3/CORBA.h>
>>
>> int main(int argc, char *argv[])
>> {
>> CORBA::ORB_ptr orb;
>>
>> orb = CORBA::ORB_init(argc, argv, "omniORB3");
>>
>> return 0;
>> }
>> EOF
>>
>> g++ bad.cpp -o bad -D__x86__ -D__linux__ -D__OSVERSION__=2 -D_REENTRANT \
>> -g -I/usr/src/omni/include \
>> -L/usr/src/omni/lib/i586_linux_2.0_glibc2.1
>> -lomniORB3 -lomniDynamic3 -ltcpwrapGK -lomnithread -lpthread
>>
>> Sai-Lai
>>
>> >>>>> Mike Perry writes:
>>
>> > Hi, I'm the author of a malloc debugger (http://fscked.org/proj/njamd.shtml),
>> > and it was recently brought to my attention that when used with omniorb v3,
>> > my debugger crashes in its init function.
>>
>> > I investigated this, and its actually crashing in glibc (2.1.3 on RH6.2),
>> > during a READ of errno (one of the save_errno assignments). This crash happens
>> > for just about any call that uses errno. Now, I'm guessing that since this
>> > happens REALLY early, the memory address errno resides in isn't mapped yet.
>> > (OmniORB calls malloc from one of its global constructors during its thread
>> > init function). My init function is called from this malloc, and then uses a
>> > number of system calls.
>>
>> > Doing a mmap on &errno stops the crash, but screws up things when debugging
>> > programs that don't have this behavior (because I remap errno and probably
>> > some important info in the page adjacent to it).
>>
>> > Ok, so I know the problem. My question now is: Is there anything that can
>> > be done about it? Can you guys map errno in earlier in the thread init
>> > proccess? Do you even handle this? I'm surprised this doesn't happen in
>> > the init function without my debugger. NJAMD works fine with pthreads, is
>> > there any way to tell omniorb to use pthreads instead of omnithreads?
>>
>> > Any help you could give would be much appreciated by both me and at least one
>> > of your users :)
>>
>> --
>> Sai-Lai Lo S.Lo@uk.research.att.com
>> AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com
>> 24a Trumpington Street Tel: +44 1223 343000
>> Cambridge CB2 1QA Fax: +44 1223 313542
>> ENGLAND
--
Sai-Lai Lo S.Lo@uk.research.att.com
AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com
24a Trumpington Street Tel: +44 1223 343000
Cambridge CB2 1QA Fax: +44 1223 313542
ENGLAND