Discussion:
[omniORB] OmniORB 4.1.6 on Intel MacOS X 10.7
Stefan Walter
2011-08-02 12:33:53 UTC
Permalink
Hi,

I am trying to make the OmniORB also running on MacOS X 10.7 with a Intel Core 2 Duo Processor.

The compilation is successful, but I am still not sure what are the correct CPP_FLAGS for this platform.

The problem is that the omniNames is crashing with a segmentation fault and in my client code the CosNaming::NamingContext::_narrow(initServ) raises a "pure virtual method called".

Can someone help me on this matter?

Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110802/804c2d71/attachment.htm
Stefan Walter
2011-08-04 21:02:54 UTC
Permalink
Hi,

I am still trying to make the omniORB working, but so far there is no break thru. I would highly appreciate if someone could help me.

I am using the following tools:
Python 2.7 for MacOS
g++ compiler: i686-apple-darwin10-llvm-g++-4.2 (this one comes with xcode)

Thanks in Advance,
Stefan
From: Stefan Walter
To:omniorb-***@omniorb-support.com
Date: 02.08.2011 10:33
Subject: OmniORB 4.1.6 on Intel MacOS X 10.7
Hi,

I am trying to make the OmniORB also running on MacOS X 10.7 with a Intel Core 2 Duo Processor.

The compilation is successful, but I am still not sure what are the correct CPP_FLAGS for this platform.

The problem is that the omniNames is crashing with a segmentation fault and in my client code the CosNaming::NamingContext::_narrow(initServ) raises a "pure virtual method called".

Can someone help me on this matter?

Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110804/40e95ec2/attachment.htm
Duncan Grisby
2011-08-05 18:21:11 UTC
Permalink
Post by Stefan Walter
I am trying to make the OmniORB also running on MacOS X 10.7 with a
Intel Core 2 Duo Processor.
The compilation is successful, but I am still not sure what are the
correct CPP_FLAGS for this platform.
How are you configuring it at present? Do you just run configure then
make?
Post by Stefan Walter
The problem is that the omniNames is crashing with a segmentation
fault and in my client code the
CosNaming::NamingContext::_narrow(initServ) raises a "pure virtual
method called".
What is happening when omniNames crashes? Can you get a stack trace
from it?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Stefan Walter
2011-08-07 15:05:29 UTC
Permalink
Dear Duncan,

I just run the ./configure script. Is that not sufficient?
gdb omniNames
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
Reading symbols for shared libraries ..... done

(gdb) r -ORBtraceLevel 40
Starting program: /Users/dev/omniORB-4.1.6/bin/omniNames -ORBtraceLevel 40
Reading symbols for shared libraries ++++......................... done
omniORB: Read from configuration file "/tmp/omniORB.cfg".
omniORB: Version: 4.1.6
omniORB: Distribution date: Fri Jul 1 15:57:00 BST 2011 dgrisby
omniORB: Skip link local address fe80::1 on interface lo0.
omniORB: Skip link local address fe80::9284:dff:fef1:ee8c on interface en1.
omniORB: My addresses are:
omniORB: 127.0.0.1
omniORB: ::1
omniORB: 10.112.3.176
omniORB: Maximum supported GIOP version is 1.2
omniORB: Native char code sets: UTF-8 ISO-8859-1.
omniORB: Transmission char code sets: UTF-8(1.2) UTF-8(1.1) ISO-8859-1(1.2) ISO-8859-1(1.1) ISO-8859-1(1.0).
omniORB: Native wide char code sets: UTF-16.
omniORB: Transmission wide char code sets: UTF-16(1.2).
omniORB: Information: the omniDynamic library is not linked.
omniORB: Current configuration is as follows:
omniORB: DefaultInitRef (file) =
omniORB: DefaultInitRef (args) =
omniORB: InitRef = NameService=corbaname::localhost
omniORB: abortOnInternalError = 0
omniORB: abortOnNativeException = 0
omniORB: acceptBiDirectionalGIOP = 0
omniORB: acceptMisalignedTcIndirections = 0
omniORB: bootstrapAgentHostname =
omniORB: bootstrapAgentPort = 900
omniORB: clientCallTimeOutPeriod = 0
omniORB: clientConnectTimeOutPeriod = 0
omniORB: clientTransportRule = * unix,ssl,tcp
omniORB: configFile = /tmp/omniORB.cfg
omniORB: connectionWatchImmediate = 0
omniORB: connectionWatchPeriod = 50000
omniORB: copyValuesInLocalCalls = 1
omniORB: diiThrowsSysExceptions = 0
omniORB: dumpConfiguration = 0
omniORB: endPoint = giop:tcp::2809
omniORB: endPointPublish = addr
omniORB: giopMaxMsgSize = 2097152
omniORB: giopTargetAddressMode = KeyAddr
omniORB: id = omniORB4
omniORB: idleThreadTimeout = 10
omniORB: immediateAddressSwitch = 0
omniORB: inConScanPeriod = 180
omniORB: lcdMode = 0
omniORB: maxGIOPConnectionPerServer = 5
omniORB: maxGIOPVersion = 1.2
omniORB: maxInterleavedCallsPerConnection = 5
omniORB: maxServerThreadPerConnection = 1
omniORB: maxServerThreadPoolSize = 100
omniORB: maxSocketRecv = 2147483647
omniORB: maxSocketSend = 2147483647
omniORB: nativeCharCodeSet = ISO-8859-1
omniORB: nativeWCharCodeSet = UTF-16
omniORB: objectTableSize = 0
omniORB: offerBiDirectionalGIOP = 0
omniORB: oneCallPerConnection = 1
omniORB: outConScanPeriod = 120
omniORB: poaHoldRequestTimeout = 0
omniORB: poaUniquePersistentSystemIds = 1
omniORB: principal = [Null]
omniORB: resetTimeOutOnRetries = 0
omniORB: scanGranularity = 5
omniORB: serverCallTimeOutPeriod = 0
omniORB: serverTransportRule = * unix,ssl,tcp
omniORB: socketSendBuffer = -1
omniORB: strictIIOP = 1
omniORB: supportBootstrapAgent = 0
omniORB: supportCurrent = 1
omniORB: supportPerThreadTimeOut = 0
omniORB: tcAliasExpand = 0
omniORB: threadPerConnectionLowerLimit = 9000
omniORB: threadPerConnectionPolicy = 1
omniORB: threadPerConnectionUpperLimit = 10000
omniORB: threadPoolWatchConnection = 1
omniORB: traceExceptions = 1
omniORB: traceFile = [stderr]
omniORB: traceInvocationReturns = 0
omniORB: traceInvocations = 0
omniORB: traceLevel = 40
omniORB: traceThreadId = 0
omniORB: traceTime = 0
omniORB: unixTransportDirectory = /tmp/omni-%u
omniORB: unixTransportPermission = 777
omniORB: useTypeCodeIndirections = 1
omniORB: validateUTF8 = 0
omniORB: verifyObjectExistsAndType = 1
omniORB: Initialising incoming endpoints.
omniORB: Instantiate endpoint 'giop:tcp::2809'
omniORB: Bind to address :: port 2809.
omniORB: Publish specification: 'addr'
omniORB: Try to publish 'addr' for endpoint giop:tcp:10.112.3.176:2809
omniORB: Publish endpoint 'giop:tcp:10.112.3.176:2809'
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
omniORB: giopRendezvouser task execute for giop:tcp:10.112.3.176:2809
omniORB: Persistent server identifier: 9b94374e0100f35b
omniORB: Adding key<NameService> (activating) to object table.
omniORB: State key<NameService> (activating) -> active

Sun Aug 7 12:49:41 2011:

Read log file successfully.
omniORB: Creating ref to local: key<NameService>
target id : IDL:omg.org/CosNaming/NamingContextExt:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000100009494 in omniNameslog::init ()
(gdb) bt
#0 0x0000000100009494 in omniNameslog::init ()
#1 0x0000000100002114 in omniNames::omniNames ()
#2 0x0000000100002812 in main ()
(gdb)
Regards,
Stefan
From: Duncan Grisby <***@grisby.org>
To:Stefan Walter <***@lisec.com>
CC:<omniorb-***@omniorb-support.com>
Date: 05.08.2011 16:23
Subject: Re: [omniORB] OmniORB 4.1.6 on Intel MacOS X 10.7
I am trying to make the OmniORB also running on MacOS X 10.7 with a
Intel Core 2 Duo Processor.
The compilation is successful, but I am still not sure what are the
correct CPP_FLAGS for this platform.
How are you configuring it at present? Do you just run configure then
make?
The problem is that the omniNames is crashing with a segmentation
fault and in my client code the
CosNaming::NamingContext::_narrow(initServ) raises a "pure virtual
method called".
What is happening when omniNames crashes? Can you get a stack trace
from it?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --



_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110807/bc30df67/attachment.htm
Loading...