Re: [ciao-users] calling Plan_Launcher leads to Execution_Manager coredump
Friedhelm Wolf
the hello example deploys w/o any problems.
Cheers,
Friedhelm
Hi Friedhelm -Thanks for using the PRF!Could you make sure the hello example deploys?!?Thanks,/-WillOn Jul 10, 2007, at 2:44 AM, Friedhelm Wolf wrote:CIAO VERSION: 0.5.8Friedhelm<StandaloneDeployment.cdp><deploy.sh>< Standalone.dat><Execution_Manager.dump>
TAO VERSION : 1.5.8
ACE VERSION : 5.5.8
HOST MACHINE and OPERATING SYSTEM:
i686 pc, SUSE linux Enterprise Server 9, Kernel 2.6.5
COMPILER NAME AND VERSION (AND PATCHLEVEL):
gcc 3.3.3 (SuSE Linux)
THE $ACE_ROOT/ace/config.h FILE:
#include "config-linux.h"
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE :
include $ACE_ROOT/include/makeinclude/platform- linux.GNU
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):
N/A
AREA/CLASS/EXAMPLE AFFECTED:
DAnCE
DOES THE PROBLEM AFFECT:
EXECUTION: Plan_Launcher / Execution_Manager
SYNOPSIS:
calling Plan_Launcher leads to Execution_Manager coredump
DESCRIPTION:
Hi there,
I try to deploy a simple component application, consisting
of two components, running on one node
(see attached StandaloneDeployment.cpd).
I followed the Simple Quoter tutorial to write a script
which starts up the necessary DAnCE executables
(see attached deploy.sh and Standalone.dat).
As a result the following output indicates a coredump:
CIAO_NodeManager IOR: IOR:010000001f00000049444c3a4349414f2f4e6f64654d616e616765724461656d6f6e3a312e300000010000000000000068000000010102000a0000006c6f63616c686f73740033831b00000014010f00525354cb339346c43908000000000001000000010000000002000000000000000800000001000000004f41540100000018000000010000000100010001000000010001050901010000000000
CIAO_NodeManager is running...
CIAO_ExecutionManager is running...
CIAO::Plan_Launcher_i: In ExecutionManager, the Priority Model Policy is not exposed. Use non-RT mode.
(28610|182977823424) Initializing the Xerces runtime
CIAO (28605|182954076800) calling this->man_.is_plan_available()...
CIAO (28605|182954076800) Plan wasn't already available
CIAO (28605|182954076800) About to instantiate CIAO::DomainApplicationManager_Impl
CORBA EXCEPTION: system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'
TAO exception, minor code = 6 (failed to recv request response; ENOENT), completed = MAYBE
Deployment failed. Plan_Launcher exiting.
./deploy.sh: line 8: 28605 Segmentation fault (core dumped) $CIAO_ROOT/DAnCE/ExecutionManager/Execution_Manager -o EM.ior -i Standalone.dat
I attached the stack of the dump file (Execution_Manager.dump).
Can you give me any hints, whats going wrong here. I generated the
deployment plan using CoSMIC. I'm not shure, if anything within there
is correct, but it seems to me, that the problem might even occur
before the deployment plan is executed by the Plan_Launcher.
Any help is appreciated.
Thanks,_______________________________________________ciao-users mailing list
_______________________________________________
ciao-users mailing list
ciao-...@mail.cse.wustl.edu
http://mail.cse.wustl.edu/mailman/listinfo/ciao-users
Gan Deng
Could you please replace your .dat file with the one attached in my
email and see whether it works better? I recall that some bug crept in
when we refactored DAnCE code in parsing CORBA LOC map configuration
file. Please let me know if this works or not.
Thanks,
Gan
> 'IDL:omg.org/CORBA/COMM_FAILURE:1.0 <http://omg.org/CORBA/COMM_FAILURE:1.0>'
> TAO exception, minor code = 6 (failed to recv request response;
> ENOENT), completed = MAYBE
>
> Deployment failed. Plan_Launcher exiting.
> ./deploy.sh: line 8: 28605 Segmentation fault (core dumped)
> $CIAO_ROOT/DAnCE/ExecutionManager/Execution_Manager -o EM.ior -i
> Standalone.dat
>
> I attached the stack of the dump file (Execution_Manager.dump).
>
> Can you give me any hints, whats going wrong here. I generated the
> deployment plan using CoSMIC. I'm not shure, if anything within there
> is correct, but it seems to me, that the problem might even occur
> before the deployment plan is executed by the Plan_Launcher.
>
> Any help is appreciated.
>
> Thanks,
> Friedhelm
>
>
> ------------------------------------------------------------------------
Friedhelm Wolf
wow ... that was a direct hit ... after putting your dat file in (I guess the tab made the difference),
I went further ...
however, I does not succeed completely but I get the following output:
CIAO_NodeManager IOR: IOR:010000001f00000049444c3a4349414f2f4e6f64654d616e616765724461656d6f6e3a312e30000001000000000000006800000001
0102000a0000006c6f63616c686f73740033831b00000014010f005253541c98934626470d0000000000010000000100000000020000000000000008000000010000
00004f41540100000018000000010000000100010001000000010001050901010000000000
CIAO_NodeManager is running...
CIAO_ExecutionManager is running...
CIAO::Plan_Launcher_i: In ExecutionManager, the Priority Model Policy is not exposed. Use non-RT mode.
CIAO (20573|182954076800) calling this->man_.is_plan_available()...
CIAO (20573|182954076800) Plan wasn't already available
CIAO (20573|182954076800) About to instantiate CIAO::DomainApplicationManager_Impl
CIAO (20573|182954076800) Instantiated CIAO::DomainApplicationManager_Impl
CIAO (20573|182954076800) Bound DAM reference...
CIAO_PlanLauncher: start Launch application...
*** Starting NodeApplication
NodeApp_Configurator::pre_orb_init
NodeApp_Configurator::post_orb_init
Running NodeApplication...
CIAO (20579|182950300544) Container_Base.cpp -Session_Container::ciao_install_home -ERROR in opening the executor DLL []
(20579|182950300544) EXCEPTION, Container_Impl::install
user exception, ID 'IDL:Deployment/UnknownImplId:1.0'
(20579|182950300544) EXCEPTION, CIAO_NodeApplication::install error
user exception, ID 'IDL:Deployment/UnknownImplId:1.0'
DAM_Impl:StartError: Session_Container::ciao_install_home, Failed to open executor DLL:
[success]
CIAO_PlanLauncher: finish Launch application...
DAM_Impl::finishLaunch - StartError: DomainApplicationManager_Impl::create_connections_i, Creating connections for LoggerComponentEn
vironment.ComponentImplementations.LoggerSystem.LoggerSystem.CLoggerClient : unable to find object reference for connection logger_lo
ggerLoggerComponentEnvironment.ComponentImplementations.LoggerSystem.LoggerSystem.CLoggerClientLoggerComponentEnvironment.ComponentI
mplementations.LoggerSystem.LoggerSystem.CLogger
[success]
CIAO_PlanLauncher: start activating components...
CORBA EXCEPTION: system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'
TAO exception, minor code = 6 (failed to recv request response; ENOENT), completed = MAYBE
Deployment failed. Plan_Launcher exiting.
Any hints on that ... as far as I can see, the needed shared objects (stub,svnt,exec) are placed in a directory which is
entered in my $LD_LIBRARY_PATH environment variable ... so they should be loadable by the SessionContainer.
BTW, I guess line 272, in $CIAO_ROOT/ciao/SessionContainer.cpp should not be
"CIAO (%P|%t) Container_Base.cpp -"
but
"CIAO (%P|%t) Session_Container.cpp -"
(I recognized some more of these lines).
Cheers,
Friedhelm
StandaloneNode corbaloc:iiop:localhost:99123/NodeManager
Johnny Willemsen
From: ciao-user...@cse.wustl.edu [mailto:ciao-user...@cse.wustl.edu] On Behalf Of Friedhelm Wolf
Sent: Tuesday, July 10, 2007 9:18 AM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_Launcher leads to Execution_Managercoredump
Gan Deng
> CIAO (20579|182950300544) Container_Base.cpp
> -Session_Container::ciao_install_home -ERROR in opening the executor
> DLL []
> (20579|182950300544) EXCEPTION, Container_Impl::install
>
> user exception, ID 'IDL:Deployment/UnknownImplId:1.0'
> (20579|182950300544) EXCEPTION, CIAO_NodeApplication::install error
>
> user exception, ID 'IDL:Deployment/UnknownImplId:1.0'
> DAM_Impl:StartError: Session_Container::ciao_install_home, Failed to
> open executor DLL:
It looks to me that the at least one DLL name in your local directory do
not match the name you specified in your deployment plan descriptor,
hence the UnknownImplId exception.
Could you please check your .cdp file and your local directory names to
make sure they do match with each other?
Thanks,
Gan
Friedhelm Wolf
It looks to me that the at least one DLL name in your local directory do
not match the name you specified in your deployment plan descriptor,
hence the UnknownImplId exception.
You were correct with that. I missed to fill in the <location> value for the
implementation artifacts of my components.
However ... when I did so, I get the same error message again (apart from
that there is the name of the .so in the debug output now):
CIAO_NodeManager IOR: IOR:010000001f00000049444c3a4349414f2f4e6f64654d616e616765724461656d6f6e3a312e300000010000000000000068000000010102000a0000006c6f63616c686f73740033831b00000014010f0052535488df9446ee7302000000000001000000010000000002000000000000000800000001000000004f41540100000018000000010000000100010001000000010001050901010000000000
CIAO_NodeManager is running...
*** Starting NodeApplication
NodeApp_Configurator::pre_orb_init
NodeApp_Configurator::post_orb_init
Running NodeApplication...
(23160|182950300544) EXCEPTION, Container_Impl::install
user exception, ID 'IDL:Deployment/UnknownImplId:1.0'
user exception, ID 'IDL:Deployment/UnknownImplId: 1.0'
Could you please check your .cdp file and your local directory names to
make sure they do match with each other?
What do you mean by local directory names? I set up my projects, so that all shared libraries are
placed in $ACE_ROOT/lib.
When the library name is "libCLogger_execd.so", i entered "CLogger_execd" as the <location> value.
I also made shure that the $ACE_ROOT/lib path is mentioned in the LD_LIBRARY_PATH variable.
However, the NodeApplications ACE_DLL_Manager seems not to be able to find the correct shared object file.
(I debugged into this the whole day now).
Any hints, why the shared objects cannot be found?
Thanks,
Friedhelm
Thanks,
Gan
Gan Deng
> When the library name is "libCLogger_execd.so", i entered
> "CLogger_execd" as the <location> value.
Could you please change it to "CLogger_exec" and see if it works better?
Basically, I suggest you follow the same naming rule as what the "Hello"
example does.
For example, you can find below tag
<location>Receiver_DnC_exec</location>
appearing in the .cdp file of Hello example. And then you can check what
the name of the library is in your $ACE_ROOT/lib directory. I suspect it
is Receiver_DnC_execd.so, right?
Thanks,
Gan
> I also made shure that the $ACE_ROOT/lib path is mentioned in the
> LD_LIBRARY_PATH variable.
>
> However, the NodeApplications ACE_DLL_Manager seems not to be able to
> find the correct shared object file.
> (I debugged into this the whole day now).
>
> Any hints, why the shared objects cannot be found?
>
>
> Thanks,
> Friedhelm
>
> Thanks,
> Gan
>
> _______________________________________________
> ciao-users mailing list
> ciao-...@mail.cse.wustl.edu <mailto:ciao-...@mail.cse.wustl.edu>
> http://mail.cse.wustl.edu/mailman/listinfo/ciao-users
>
>
>
> ------------------------------------------------------------------------
Gan Deng
> Hi Friedhelm,
>
>> When the library name is "libCLogger_execd.so", i entered
>> "CLogger_execd" as the <location> value.
>
> Could you please change it to "CLogger_exec" and see if it works better?
> Basically, I suggest you follow the same naming rule as what the "Hello"
> example does.
>
> For example, you can find below tag
>
> <location>Receiver_DnC_exec</location>
>
> appearing in the .cdp file of Hello example. And then you can check what
> the name of the library is in your $ACE_ROOT/lib directory. I suspect it
> is Receiver_DnC_execd.so, right?
Sorry, I meant libReceiver_DnC_execd.so.
Thanks,
Gan
Friedhelm Wolf
>> When the library name is "libCLogger_execd.so", i entered
>> "CLogger_execd" as the <location> value.
>
> Could you please change it to "CLogger_exec" and see if it works better?
> Basically, I suggest you follow the same naming rule as what the "Hello"
> example does.
I tried to do that without success. I now have to versions of the libraries residing
in $ACE_ROOT/lib (the debug version with *d.so naming convention, and the release version).
I tried both versions <location>CLogger_exec</location>, and <location>CLogger_execd</location>
without success.
>
> For example, you can find below tag
>
> <location>Receiver_DnC_exec</location>
>
> appearing in the .cdp file of Hello example. And then you can check what
> the name of the library is in your $ACE_ROOT/lib directory. I suspect it
> is Receiver_DnC_execd.so, right?
Sorry, I meant libReceiver_DnC_execd.so.
I just built the release version of ACE/TAO/CIAO and then made symbolic links
for the lib*d.so libraries, which just reference the release versions.
For my component projects however, I used the "Debug configuration"
for MPC (using -type make and setting configurations = Debug in $ACE_ROOT/MPC/templates/user_makedll.mpt).
But to check if that is a problem, I built my components using the
"Release configuration" too. And the same problem occured.
So I guess, this is not the problem.
Friedhelm
Krishnakumar B
On Thu, 12 Jul 2007 04:39:55 AM -0500, Friedhelm Wolf wrote:
> Gan,
>
>>> When the library name is "libCLogger_execd.so", i entered
>> >> "CLogger_execd" as the <location> value.
>> >
>> > Could you please change it to "CLogger_exec" and see if it works better?
>> > Basically, I suggest you follow the same naming rule as what the "Hello"
>> > example does.
>
> I tried to do that without success. I now have to versions of the
> libraries residing in $ACE_ROOT/lib (the debug version with *d.so naming
> convention, and the release version). I tried both versions
> <location>CLogger_exec</location>, and <location>CLogger_execd</location>
> without success.
Can you please give the exact list of commands that you used to create
Makefiles? Are you still using SuSE (from your original PRF) or have you
switched to using Windows? All talk about *d and DLL et al doesn't make
sense on SuSE. How did you generate the MPC file for your components? Did
you use $ACE_ROOT/bin/generate_component_mpc.pl or did you write it by
hand?
Given a component Foo, you should have the following libraries under
$ACE_ROOT/lib:
Windows (Debug)
Foo_execd.dll
Foo_svntd.dll
Foo_stubd.dll
Windows (Release)
Foo_exec.dll
Foo_svnt.dll
Foo_stub.dll
Linux (Both Debug and Release)
libFoo_exec.so.0.5.8
libFoo_svnt.so.0.5.8
libFoo_stub.so.0.5.8
If you don't have these libraries, then you have a problem. Assuming you
do have these libraries, make sure that you enter Foo_exec in the location
field in CoSMIC corresponding to the Foo_Exec ImplementationArtifact. BTW,
please also make sure that you do File->Check->Check All to check all the
constraints before you generate a deployment plan using CoSMIC.
>> > For example, you can find below tag
>> >
>> > <location>Receiver_DnC_exec</location>
>> >
>> > appearing in the .cdp file of Hello example. And then you can check what
>> > the name of the library is in your $ACE_ROOT/lib directory. I suspect it
>> > is Receiver_DnC_execd.so, right?
>>
>> Sorry, I meant libReceiver_DnC_execd.so.
>
> I just built the release version of ACE/TAO/CIAO and then made symbolic
> links for the lib*d.so libraries, which just reference the release
> versions.
Please don't do any of these tricks. It becomes a nightmare to track down
the problems. Either keep separate workspaces or use the
$ACE_ROOT/bin/create_ace_build.pl to create multiple build configurations
with the same source tree.
> For my component projects however, I used the "Debug configuration" for
> MPC (using -type make and setting configurations = Debug in
> $ACE_ROOT/MPC/templates/user_makedll.mpt). But to check if that is a
> problem, I built my components using the "Release configuration" too. And
> the same problem occured. So I guess, this is not the problem.
Your using -type make to MPC is the problem. You should use
$ACE_ROOT/bin/mwc.pl -type gnuace <something.mwc>
to build CIAO on Linux. And don't modify anything under
$ACE_ROOT/MPC/templates unless you know what you are doing.
Hope this helps.
-kitty.
--
Krishnakumar B <kitty at dre dot vanderbilt dot edu>
Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University
Friedhelm Wolf
Can you please give the exact list of commands that you used to create
Makefiles? Are you still using SuSE (from your original PRF) or have you
switched to using Windows? All talk about *d and DLL et al doesn't make
I'm sorry, if I mixed terms somewhere. I'm still on Linux using .so libraries.
sense on SuSE. How did you generate the MPC file for your components? Did
you use $ACE_ROOT/bin/generate_component_mpc.pl or did you write it by
hand?
Exactly, I used the perl script and adopted the project to my needs afterwarts,
because I had to integrate several existing libraries to implement the component.
If you don't have these libraries, then you have a problem. Assuming you
do have these libraries, make sure that you enter Foo_exec in the location
field in CoSMIC corresponding to the Foo_Exec ImplementationArtifact. BTW,
please also make sure that you do File->Check->Check All to check all the
constraints before you generate a deployment plan using CoSMIC.
The CoSMIC model is correct and I checked the implementation artifact entries.
>> > For example, you can find below tag
>> >
>> > <location>Receiver_DnC_exec</location>
>> >
>> > appearing in the .cdp file of Hello example. And then you can check what
>> > the name of the library is in your $ACE_ROOT/lib directory. I suspect it
>> > is Receiver_DnC_execd.so, right?
>>
>> Sorry, I meant libReceiver_DnC_execd.so.
It's libReceiver_DnC_exec.so for me, because I did not build ACE/TAO as a debug version.
> I just built the release version of ACE/TAO/CIAO and then made symbolic
> links for the lib*d.so libraries, which just reference the release
> versions.
Please don't do any of these tricks. It becomes a nightmare to track down
the problems. Either keep separate workspaces or use the
$ACE_ROOT/bin/create_ace_build.pl to create multiple build configurations
with the same source tree.
Ok, I got rid of the links and I am now using the release configuration consistently
within CIAO and my component projects.
Your using -type make to MPC is the problem. You should use
$ACE_ROOT/bin/mwc.pl -type gnuace <something.mwc>
As far as I understood, the gnuace build type is mainly to build ACE/TAO/CIAO
itself and the standard make build type is more suitable for projects outside the
CIAO source tree (and I consider my component project as a standalone project).
to build CIAO on Linux. And don't modify anything under
$ACE_ROOT/MPC/templates unless you know what you are doing.
What I'm planning to do now, is to integrate my project into the CIAO source
tree and make it as similar to a running example as possible to
narrow the problem down.
Hope this helps.
Thanks a lot, your help is appriciated very much.
Cheers,
Friedhelm
Friedhelm Wolf
after some struggling, I managed to get a running deployment.
The reason it didn't work seemed to be some problems with .so dependencies.
However, I've got some problems with the next step:
I have a running component, called CLoggerClient, which has the following interface:
interface ILogAMessage
{
void logthis (
in string message
);
};
component CLoggerClient supports ILogAMessage
{
uses ILogger logger;
attribute long cycleTime;
attribute string cyclicMessage;
};
I implemented a small executable, according to the starter in the Hello example,
which just calls to method LogAMessage::logthis () on the CLoggerClient.
Here is the corresponding code snippet:
CORBA::Object_var obj =
orb->string_to_object (loggerclient_ior);
// narrow to a reference of the CLoggerClient component
CLoggerClient_var loggerclient = CLoggerClient::_narrow ( obj.in ());
if (CORBA::is_nil (loggerclient.in ()))
{
ACE_ERROR_RETURN ((LM_ERROR,
"Unable to acquire LoggerClient's objref\n"),
-1);
}
loggerclient->logthis (CORBA::string_dup (logmessage));
However, the last call fails with the following output:
(20395|182924465856) EXCEPTION, Unknown exception
system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'
TAO exception, minor code = 6 (failed to recv request response; ENOENT), completed = MAYBE
The CLoggerClient also gives some info, what happens:
TAO (20208|182956442240) - Transport[9]::handle_input
TAO (20208|182956442240) - Transport[9]::process_queue_head, 0 enqueued
TAO (20208|182956442240) - Transport[9]::handle_input_parse_data, enter
TAO (20208|182956442240) - Transport[9]::handle_input, error parsing incoming message
TAO (20208|182956442240) - Connection_Handler[9]::close_connection_eh, purging entry from cache
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - Connection_Handler[9]::close_connection_eh, removing from the reactor
TAO (20208|182956442240) - Connection_Handler[9]::close_connection_eh, cancel all timers
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - Connection_Handler[9]::close_connection_eh
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[9]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20209|182954076800) - Transport[10]::handle_input
TAO (20209|182954076800) - Transport[10]::process_queue_head, 0 enqueued
TAO (20209|182954076800) - Transport[10]::handle_input_parse_data, enter
TAO (20209|182954076800) - Transport[10]::handle_input, error parsing incoming message
TAO (20209|182954076800) - Connection_Handler[10]::close_connection_eh, purging entry from cache
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20209|182954076800) - Connection_Handler[10]::close_connection_eh, removing from the reactor
TAO (20209|182954076800) - Connection_Handler[10]::close_connection_eh, cancel all timers
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20209|182954076800) - Connection_Handler[10]::close_connection_eh
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20209|182954076800) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - ORB_Core::run, handle_events() returns 0
TAO (20208|182956442240) - ORB_Core::run, calling handle_events()
TAO (20209|182954076800) - ORB_Core::run, handle_events() returns 0
TAO (20209|182954076800) - ORB_Core::run, calling handle_events()
TAO (20208|182956442240) - Transport[10]::handle_input
TAO (20208|182956442240) - Transport[10]::process_queue_head, 0 enqueued
TAO (20208|182956442240) - Transport[10]::handle_input_parse_data, enter
TAO (20208|182956442240) - Transport[10]::handle_input, error parsing incoming message
TAO (20208|182956442240) - Connection_Handler[10]::close_connection_eh, purging entry from cache
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - Connection_Handler[10]::close_connection_eh, removing from the reactor
TAO (20208|182956442240) - Connection_Handler[10]::close_connection_eh, cancel all timers
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - Connection_Handler[10]::close_connection_eh
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, cleaning up complete queue
TAO (20208|182956442240) - Transport[10]::cleanup_queue_i, discarded 0 messages, 0 bytes.
TAO (20208|182956442240) - ORB_Core::run, handle_events() returns 0
TAO (20208|182956442240) - ORB_Core::run, calling handle_events()
If I understand this correctly, there is something going wrong on a rather low level,
because the component cannot decode the request from the executable,
according to the message:
TAO (20208|182956442240) - Transport[9]::handle_input, error parsing incoming message
Do you have any advice, where I should start from to narrow down the failure?
Thanks,
Friedhelm
Hi Friedhelm -
On Jul 16, 2007, at 12:39 PM, Friedhelm Wolf wrote:
> Kity,
>
> Can you please give the exact list of commands that you used to create
> Makefiles? Are you still using SuSE (from your original PRF) or
> have you
>
> I'm simply using $ACE_ROOT/bin/mwc.pl -type make
>
Bad juju right here, you should be using gnuace instead of make.
/-Will
Johnny Willemsen
Can you run the application with -ORBDebugLevel 10? Are both programs TAO or are you also using another ORB?
Sent: Tuesday, July 24, 2007 1:32 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_Launcher leads to Execution_Managercoredump
Johnny Willemsen
Sent: Tuesday, July 24, 2007 5:07 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_Launcher leads toExecution_Managercoredump
Hi Johnny,
Can you run the application with -ORBDebugLevel 10? Are both programs TAO or are you also using another ORB?
See the attatched file for the output with -ORBDebugLevel 10.
Both programs use the same version of TAO, as given in the initial PRF.
Thanks,
Friedhelm
Johnny Willemsen
Sent: Tuesday, July 24, 2007 5:20 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_Launcher leadstoExecution_Managercoredump
Hi Johnny,
Looks like the program you call closes the connection. Can you also provide the log of the other side?
See attatched file for the complete log output of the running deployment until the connection
effort of the executable.
Thanks,
Friedhelm
Johnny Willemsen
TAO (24614|182954076800) - Transport[10]::cleanup_queue, after transfer, bc = 0, all_sent = 1, ml = 0
TAO (24614|182954076800) - Transport[10]::drain_queue_helper, byte_count = 582, head_is_empty = 1
TAO (24614|182954076800) - Transport[10]::drain_queue_i, helper retval = 1
TAO (24614|182954076800) - Transport[10]::make_idle
TAO (24614|182954076800) - Leader_Follower[10]::wait_for_event, (leader) enter reactor event loop
Unable to find policies for the receptacle logger_LoggerComponentEnvironment.ComponentImplementations.LoggerSystem.LoggerSystem.CLoggerClient
In Servant_Impl_Base::add_receptacle (logger)
Found no receptacle named (logger)
Successfully added new receptacle named (logger)
Sent: Wednesday, July 25, 2007 12:07 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_LauncherleadstoExecution_Managercoredump
Hi Johnny,
Are you really sure the client connects to the correct server? The client connects to 131.176.53.15 and then port 33137 but in the server log I don't see any reference to post 33137.
As I found out, I forgot to give the -ORBDebug option to the DAnCE NodeApplications, which are started, so the server log was not complete.
The IOR I am using to connect to the CLoggerClient component is generated automatically by the Container_Impl class.
I attatched the catior output, which looks good as well. In the new log, there is a connection on the corresponding port,
so I guess, the correct server is addressed.
Any other hints?
Thanks,
Friedhelm
Johnny
From: ciao-user...@cse.wustl.edu [mailto:ciao-user...@cse.wustl.edu] On Behalf Of Friedhelm Wolf
Sent: Tuesday, July 24, 2007 5:20 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] calling Plan_Launcher leadstoExecution_ManagercoredumpHi Johnny,
Looks like the program you call closes the connection. Can you also provide the log of the other side?
See attatched file for the complete log output of the running deployment until the connection
effort of the executable.
Thanks,
Friedhelm
Friedhelm Wolf
In the log I see the output below. Is this expected?JohnnyTAO (24614|182954076800) - Transport[10]::cleanup_queue, byte_count = 582
TAO (24614|182954076800) - Transport[10]::cleanup_queue, after transfer, bc = 0, all_sent = 1, ml = 0
TAO (24614|182954076800) - Transport[10]::drain_queue_helper, byte_count = 582, head_is_empty = 1
TAO (24614|182954076800) - Transport[10]::drain_queue_i, helper retval = 1
TAO (24614|182954076800) - Transport[10]::make_idle
TAO (24614|182954076800) - Leader_Follower[10]::wait_for_event, (leader) enter reactor event loop
The first part of the log seems rather normal. Right? The Orb just listens on the connection.
Unable to find policies for the receptacle logger_LoggerComponentEnvironment.ComponentImplementations.LoggerSystem.LoggerSystem.CLoggerClient
In Servant_Impl_Base::add_receptacle (logger)
Found no receptacle named (logger)
Successfully added new receptacle named (logger)
I assume that this message is not a problem, because it appears in the Hello example as well,
and the problem I have does not occur there.
Thanks,
Friedhelm
Gan Deng
Yes, Friedhelm is right here. These messages are some debugging output
from CIAO internal, which are all normal.
Thanks,
Gan
Johnny Willemsen
The log just tells me enough what is happening. Can you maybe run your app in the debugger and see what is received in the server?
Sent: Wednesday, July 25, 2007 1:34 PM
To: CIAO Users Mailing List
Subject: Re: [ciao-users] callingPlan_LauncherleadstoExecution_Managercoredump
Johnny,
In the log I see the output below. Is this expected?JohnnyTAO (24614|182954076800) - Transport[10]::cleanup_queue, byte_count = 582
TAO (24614|182954076800) - Transport[10]::cleanup_queue, after transfer, bc = 0, all_sent = 1, ml = 0
TAO (24614|182954076800) - Transport[10]::drain_queue_helper, byte_count = 582, head_is_empty = 1
TAO (24614|182954076800) - Transport[10]::drain_queue_i, helper retval = 1
TAO (24614|182954076800) - Transport[10]::make_idle
TAO (24614|182954076800) - Leader_Follower[10]::wait_for_event, (leader) enter reactor event loop
The first part of the log seems rather normal. Right? The Orb just listens on the connection.Unable to find policies for the receptacle logger_LoggerComponentEnvironment.ComponentImplementations.LoggerSystem.LoggerSystem.CLoggerClient
In Servant_Impl_Base::add_receptacle (logger)
Found no receptacle named (logger)
Successfully added new receptacle named (logger)
I assume that this message is not a problem, because it appears in the Hello example as well,
and the problem I have does not occur there.
Thanks,
Friedhelm
Friedhelm Wolf
after having another close look, I have to correct my assumptions.
In the stack, the call arrives at CLoggerClient_exec_i correctly (frame 17)
and triggers a collocated call to CLogger, using a receptacle/facet
connection. This call is dispatched until it ends up in the
CLogger_svnt.cpp.
Maybe there's something wrong with collocated calls, when two components exist
within the same node application? Did I forget to initialize something here?
Thanks,
Friedhelm
On 7/26/07, Friedhelm Wolf <friedhe...@googlemail.com> wrote:
> Hi Johnny,
>
> > The log just tells me enough what is happening. Can you maybe run your app
> > in the debugger and see what is received in the server?
>
> debugging the whole thing was not easy, but it helped a lot:
> I found out, that actually the whole node application seg faults, when
> the request
> is coming in (I could have realized that, if I'd had a look at the
> running processes,
> because behind the NodeApllication, there was the hint <defunct>).
>
> Actually the code, where the application crashes is autogenerated by the
> idl compiler, so maybe some CIAO people can help here.
>
> I attatched the stackdump. The codesnippet, where the whole thing crashes is:
>
> template <typename T>
> void
> ILogger_Servant_T<T>::WriteMessage (
> const char * messageSource,
> const char * messageType,
> const char * messageText
> )
> {
> this->executor_->WriteMessage (
> messageSource,
> messageType,
> messageText
> );
> }
>
> The reason for crashing is, that the executor_ member variable is a var
> class containing a null pointer at that moment.
>
> However, this is very strange because I do not want to connect to the
> CLogger component (to which the call seems to be delivered according
> to the stackdump), but to the CLoggerClient.
>
> After thinking about that, I have to assumptions:
> 1. Maybe the IOR generation mechanism in CIAO isn't working correctly
> all the time and I therefore end up in the wrong component.
> 2. It is not allowed to deploy two components to the same container,
> as I did (see attached deployment plan).
>
> Any comments on that?
>
> Thanks,
> Friedhelm
>
> On 7/26/07, Johnny Willemsen <jwill...@remedy.nl> wrote:
> >
> >
> > Hi,
Friedhelm Wolf
> Maybe there's something wrong with collocated calls, when two components exist
> within the same node application? Did I forget to initialize something here?
I could reproduce the same problem when deploying the components in two
separate NodeApplications. It segfaulted at exactly the same point.
This means that there seems to be something wrong with the initialization
of the Components, is that correct?
Thanks,
Friedhelm
Sowayan, Abdullah (N-DUA)
> I could reproduce the same problem when deploying the components in
two
> separate NodeApplications. It segfaulted at exactly the same point.
> This means that there seems to be something wrong with the
initialization
> of the Components, is that correct?
I haven't closely followed this thread of discussion. Quick comment
though, CCM has an initialization sequence, look at
CIAO_ROOT\docs\imgs\DAnCE-Dynamic.png
Try not doing anything until after ccm_activate (i.e., don't do stuff
before everything is initialized properly). If you're spawning threads
to do some work, try doing it in ciao_postactivate.
Thanks,
Abdul
Gan Deng
Could you please make sure that you didn't use any wonrg/obsolete IORs
generated by CIAO, since you mentioned it tries to connect to the wrong
component? Before investigating this problem further, I would suggest
delete all the IOR files generated by CIAO in the directory of your file
system and try again.
Thanks,
Gan
>> ------------------------------------------------------------------------
Sowayan, Abdullah (N-DUA)
> >> I could reproduce the same problem when deploying the components in
> > two
> >> separate NodeApplications. It segfaulted at exactly the same point.
> >> This means that there seems to be something wrong with the
> > initialization
> >> of the Components, is that correct?
> >
> > I haven't closely followed this thread of discussion. Quick comment
> > though, CCM has an initialization sequence, look at
> > CIAO_ROOT\docs\imgs\DAnCE-Dynamic.png
> >
>
> If memory serves, Friedhelm is actually the author of that image ;-)
Oh, LOL. Well in that case, thank you very much Friedhelm for
contributing that image. I have a big print out of it on the Lab's Wall.
It really helped me understand what DAnCE and CIAO are doing.
Thanks,
Abdul
Friedhelm Wolf
> I haven't closely followed this thread of discussion. Quick comment
> though, CCM has an initialization sequence, look at
> CIAO_ROOT\docs\imgs\DAnCE-Dynamic.png
The deployment was successfull and the whole component application is
running, when this error occurs. What I actually do is, to trigger a component
interaction (CLoggerClient will use its logger receptacle to call a
facet of CLogger) via a call to CLoggerClient through a supported
interface.
> Try not doing anything until after ccm_activate (i.e., don't do stuff
> before everything is initialized properly). If you're spawning threads
> to do some work, try doing it in ciao_postactivate.
I do not spawn any threads or something like this.
Thanks,
Friedhelm
Friedhelm Wolf
> If memory serves, Friedhelm is actually the author of that image ;-)
:-)
> Friedhelm - are you sure you are compiling with debug on, inline off,
> and optimization off, ie:
>
> debug=1
> inline=0
> optimize=0
I have to admit, that inline and optimization are not set to 0 in my
ACE/TAO/CIAO
build. I know that it is kind of inconvinient to have inline on, but I
know how to handle
this while debugging. Optimization is another issue.
> in your platform_macros.GNU file. Compiling with other settings can
> play hell with the stack traces reported by gdb.
In this case I really debugged into the process and the stack seems to
look alright.
I even could examine the data of the _var class, so I consider the
backtrace rather reliable.
However, I will rebuild ACE with the settings you proposed, to be totally shure.
Thanks,
Friedhelm
Friedhelm Wolf
> Could you please make sure that you didn't use any wonrg/obsolete IORs
> generated by CIAO, since you mentioned it tries to connect to the wrong
> component? Before investigating this problem further, I would suggest
> delete all the IOR files generated by CIAO in the directory of your file
> system and try again.
I did this already. The IORs are really created on application startup.
And as I wrote I have to correct myself, the IORs are acutally working fine.
The components are referenced and called correctly.
It's just, that the CLogger component seems to have some problems in the
method (WriteMessage) I mentioned above. I attached the whole generated file.
What I will do next is, to compare this _svnt.cpp file to the one in
the Hello example,
maybe I find some differences, which explain this behavior.
Thanks,
Friedhelm
Friedhelm Wolf
I had a close look at my code and I recognized that I forgot to implement
the CLogger_exec_i::get_logger () method in my executor. This definitely
explains, where this reference is not available, when a message should
be dispatched to it. I have to confirm this yet, but recompiling the correct
code (my ACE/TAO/CIAO build without optimization options is still running
;-) ), but I guess that was it.
Thanks for all your help and keeping me digging deeper into the problem.
Cheers,
Friedhelm
On 7/26/07, Friedhelm Wolf <friedhe...@googlemail.com> wrote:
> Hi Gan,
>
> I forgot the file. Here it comes.
>
> Thanks,
> Friedhelm
>
> On 7/26/07, Friedhelm Wolf <friedhe...@googlemail.com> wrote:
Friedhelm Wolf
implemented the get_logger() method.
Johnny Willemsen
Is there a way that we could trigger a compile error or add debugging info
so that this is easier to detect?
Johnny
> -----Original Message-----
> From: ciao-user...@cse.wustl.edu
> [mailto:ciao-user...@cse.wustl.edu] On Behalf Of Friedhelm Wolf
> Sent: Friday, July 27, 2007 3:52 PM
> To: CIAO Users Mailing List
> Subject: Re:
> [ciao-users]callingPlan_LauncherleadstoExecution_Managercoredump
>
Sowayan, Abdullah (N-DUA)
> Is there a way that we could trigger a compile error or add debugging
info
> so that this is easier to detect?
Sure we can. The CIDLC compiler generates code in the executor
implementation that would return a nil reference by default. If we have
it not generate that code (or generate it commented out) the executor
won't compile unless you provide the implementation (or remove the
comment). Optionally, we can have this (whether to produce default
implementation or not) as a configuration parameter to the CIDLC
compiler.
Thanks,
Abdul
Krishnakumar B
On Fri, 27 Jul 2007 01:04:48 PM -0500, Sowayan, Abdullah (N-DUA) wrote:
> Johnny,
>
>> Is there a way that we could trigger a compile error or add debugging
> info
>> so that this is easier to detect?
>
> Sure we can. The CIDLC compiler generates code in the executor
> implementation that would return a nil reference by default. If we have
> it not generate that code (or generate it commented out) the executor
> won't compile unless you provide the implementation (or remove the
> comment).
This is the way to go! We don't need to worry about generated code
compiling.
Johnny Willemsen
Abdul, can you file this in bugzilla as enhancement?
Johnny
> -----Original Message-----
> From: ciao-user...@cse.wustl.edu
> [mailto:ciao-user...@cse.wustl.edu] On Behalf Of Krishnakumar B
> Sent: Friday, July 27, 2007 8:46 PM
> To: CIAO Users Mailing List
> Subject: Re:
> [ciao-users]callingPlan_LauncherleadstoExecution_Managercoredump
>
Sowayan, Abdullah (N-DUA)
> Abdul, can you file this in bugzilla as enhancement?
Sure, no problem.
Thanks,
Abdul