[tao-users] COMM_FAILURE:1.0 minor code 6
marco
I have a problem with calling methods on Corba-objects after I've called a
method on a Corba-Object that is activated by an ACE_Service-class.
TAO VERSION: 1.3
ACE VERSION: 5.3
HOST MACHINE and OPERATING SYSTEM:
intel Pentium II 266Mhz / SuSE Linux 8.0
COMPILER NAME AND VERSION (AND PATCHLEVEL):
g++ 2.95.3
AREA AFFECTED:
Calling a Corba-object after calling a method on a Corba-Object that is
activated by an ACE_Service-class.
DOES THE PROBLEM AFFECT:
COMPILATION?
No.
LINKING?
No.
EXECUTION?
Yes.
SYNOPSIS:
1.) The server-executable activates a DLL_ORB, starts the Corba-object SERVER
and registers it with the NameService.
2.) The client starts a ACE_Service-class SERVICE calling a method on SERVER.
SERVICE activates a Corba-object SOMEOBJECT and registers it with the
NameService.
3.) The client calls a method SOMEMETHOD on SOMEOBJECT. After that every
succeeding Corba-call on SERVER or SOMEOBJECT fails. The client fails with
the following error:
"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 server dies with a segmentation fault.
DESCRIPTION:
The server opens the ACE_Service_Config with the following svc.conf:
--- begin svc.conf ---
# Define a special Reactor for single-threaded configurations.
dynamic Resource_Factory Service_Object *
./Services/MARVIN_Services:_make_My_Resource_Factory()
# Dynamically configure the ORB into the application process.
dynamic ORB Service_Object * ./Services/MARVIN_Services:_make_DLL_ORB() "dummy
-ORBInitRef NameService=file://naming_service.ior -n ORB"
--- end svc.conf ---
SERVICE and SOMEOBJECT are in the same process and are both using the DLL_ORB
which was activated by the server-executable. SOMEMETHOD calls a method on
SERVER via Corba. If I ommit the Corba-communication in SOMEMETHOD I don't
get this behaviour (and no functionality :( ...)
I hope, that I have supplied enough info to point me to right direction.
Please let me know if and what kind of additional infornation is required to
better understand the problem.
Thanks in advance,
Marco Wedekind
marco
I've done some debugging on the problem.
TAO VERSION: 1.3
ACE VERSION: 5.3
HOST MACHINE and OPERATING SYSTEM:
intel Pentium II 266Mhz / SuSE Linux 8.0
COMPILER NAME AND VERSION (AND PATCHLEVEL):
g++ 2.95.3
AREA AFFECTED:
Calling a Corba-object after calling a method on a Corba-Object that is
activated by an ACE_Service-class.
DOES THE PROBLEM AFFECT:
COMPILATION?
No.
LINKING?
No.
EXECUTION?
Yes.
SYNOPSIS:
The first call to a Corba-object succeeds while the second call to this or any
other Corba-object fails.
DESCRIPTION:
There is a problem with receiving the reply from a Twoway-Invocation. The
TAO_GIOP_Twoway_Invocation::invoke-method is called by the
_TAO..._Remote_Proxy_Impl in my stub-file (...C.cpp) which was generated from
an idl-file:
TAO_GIOP_Twoway_Invocation::invoke (this=0xbfffeda0, excepts=0x0,
except_count=0) at Invocation.cpp:902
L> TAO_GIOP_Synch_Invocation::invoke_i (this=0xbfffeda0, is_locate_request=64
'@') at Invocation.cpp:599
L> TAO_Wait_On_Leader_Follower::wait (this=0x80f4bf0, max_wait_time=0x0,
rd=@0xbffff078) at Wait_On_Leader_Follower.cpp:52
L> TAO_Leader_Follower::wait_for_event (this=0x80d8ed0, event=0xbffff080,
transport=0x80f4b50, max_wait_time=0x0) at Leader_Follower.cpp:447
426 // Return an error if there was a problem receiving the reply...
427 if (max_wait_time != 0)
428 {
...
441 }
442 else
443 {
444 result = 0;
445 if (event->error_detected ())
446 {
--> 447 result = -1;
448 }
L> TAO_LF_CH_Event::error_detected (this=0x80f4700) at LF_CH_Event.cpp:91
92 if (this->prev_state_ == TAO_LF_Event::LFS_CONNECTION_WAIT)
93 return this->state_ == TAO_LF_Event::LFS_CONNECTION_CLOSED;
94 else if (this->prev_state_ ==
TAO_LF_Event::LFS_CONNECTION_CLOSE_WAIT)
--> 95 return (this->state_ != TAO_LF_Event::LFS_CONNECTION_CLOSED);
The arrows (-->) point to the sourcelines where the error is found. I don't
know what is wrong with my configuration or usage of ACE+TAO. I didn't find
anything about that in the newsgroups. Any help is appreciated.
Thanks,
Marco Wedekind
Balachandran Natarajan
On Sunday, 23 March, 2003 at 13:14:22 +0100, marco wrote:
> I've done some debugging on the problem.
>
> TAO VERSION: 1.3
> ACE VERSION: 5.3
Thanks for using the PRF!
> HOST MACHINE and OPERATING SYSTEM:
> intel Pentium II 266Mhz / SuSE Linux 8.0
>
> COMPILER NAME AND VERSION (AND PATCHLEVEL):
> g++ 2.95.3
>
> AREA AFFECTED:
> Calling a Corba-object after calling a method on a Corba-Object
> that is activated by an ACE_Service-class.
Could you please explain what you mean by ACE_Service class?
> DOES THE PROBLEM AFFECT:
> COMPILATION?
> No.
> LINKING?
> No.
> EXECUTION?
> Yes.
>
> SYNOPSIS:
> The first call to a Corba-object succeeds while the second call to
> this or any other Corba-object fails.
Hmm.. Sounds odd..
>
> DESCRIPTION:
>
> There is a problem with receiving the reply from a Twoway-Invocation. The
> TAO_GIOP_Twoway_Invocation::invoke-method is called by the
> _TAO..._Remote_Proxy_Impl in my stub-file (...C.cpp) which was
> generated from
> an idl-file:
>
> TAO_GIOP_Twoway_Invocation::invoke (this=0xbfffeda0, excepts=0x0,
> except_count=0) at Invocation.cpp:902
>
> L> TAO_GIOP_Synch_Invocation::invoke_i (this=0xbfffeda0, is_locate_request=64
[snipped]
> The arrows (-->) point to the sourcelines where the error is
> found. I don't know what is wrong with my configuration or usage
> of ACE+TAO. I didn't find anything about that in the
> newsgroups. Any help is appreciated.
I dont find anything amiss. That is regular path followed by a thread
if a server closes connection (like crashing) when the client thread
is waiting for the reply. It would be hard for us to help you without
more detail about the problem!
Thanks
Bala
marco
thanks for your reply.
On Sun, 2003-03-23 at 23:42, Balachandran Natarajan wrote:
> > AREA AFFECTED:
> > Calling a Corba-object after calling a method on a Corba-Object
> > that is activated by an ACE_Service-class.
>
> Could you please explain what you mean by ACE_Service class?
I've implemented the ACE_Service_Object like this:
--
#ifndef MARVIN_Script_Management_Service__h
#define MARVIN_Script_Management_Service__h
#include <iostream>
#include "ace/Service_Config.h"
#include "ace/Get_Opt.h"
#include "tao/debug.h"
#include "DLL_ORB.h"
#include
"../../Script_Management/CORBA_Proxy/Script_Management_CORBA_Proxy.h"
class ACE_Svc_Export Script_Management_Service : public
ACE_Service_Object
{
public:
Script_Management_Service();
~Script_Management_Service();
virtual int init (int argc, char *argv[]);
virtual int suspend (void);
virtual int resume (void);
virtual int info (char **, size_t) const;
virtual int fini (void);
private:
const char *name_;
const char *orb_;
TAO_ORB_Manager orb_manager_;
TAO_Naming_Server naming_server_;
MARVIN_Script_Management_Module_MARVIN_Script_Management_CORBA_Proxy_i
servant_;
int parse_args(int argc, char *argv[]);
int register_name();
};
ACE_SVC_FACTORY_DECLARE (Script_Management_Service)
#endif /* MARVIN_Script_Management_Service__h */
--
The init()-method registers the Corba-proxy of the class
Script_Management with the NameService and activates the Corba-proxy:
--
int Script_Management_Service::init(int argc, char *argv[])
{
ACE_TRY_NEW_ENV
{
ACE_DEBUG ((LM_DEBUG,
"\n\tScript_Management_Service servant\n\n"));
this->parse_args (argc, argv);
DLL_ORB *orb =
ACE_Dynamic_Service<DLL_ORB>::instance (this->orb_);
if (orb == 0)
{
ACE_ERROR_RETURN ((LM_ERROR,
"Script_Management_Service::init():\n" \
"\tCan't find %s in the Service Repository\n",
this->orb_),
-1);
}
this->orb_manager_ = orb->orb_manager_;
if (this->orb_manager_.init_child_poa(
argc,
argv,
"Script_Management") == -1)
{
ACE_ERROR_RETURN ((LM_ERROR,
"%p\n",
"Script_Management_Service::init()\n"),
-1);
}
ACE_CHECK_RETURN (-1);
this->name_ = "Script_Management";
if (this->register_name() == -1)
{
ACE_ERROR_RETURN ((LM_ERROR,
"Script_Management_Service::init()\n" \
"\tError while registering with " \
"Naming Service.\n"),
-1);
}
}
ACE_CATCHANY
{
ACE_PRINT_EXCEPTION (ACE_ANY_EXCEPTION,
"Script_Management_Service::init()\n");
return -1;
}
ACE_ENDTRY;
return 0;
}
--
The method register_name() looks like this:
--
int Script_Management_Service::register_name()
{
CORBA::ORB_var orb = this->orb_manager_.orb();
PortableServer::POA_var child_poa =
this->orb_manager_.child_poa();
this->naming_server_.init(orb.in(),
child_poa.in(),
ACE_DEFAULT_MAP_SIZE,
0,
1, /* resolve existing name service */
0,
TAO_NAMING_BASE_ADDR,
0 /* no multicast */);
ACE_DEBUG((LM_DEBUG,
"Script_Management_Service::register_name()\n" \
"\tNameserver initialization done...\n"));
ACE_TRY
{
CORBA::Object_var sm = servant_._this();
this->orb_manager_.activate_poa_manager ();
CosNaming::Name name;
name.length (1);
name[0].id = CORBA::string_dup (this->name_);
this->naming_server_->rebind(
name,
sm.in());
}
ACE_CATCH (CosNaming::NamingContext::AlreadyBound, albe)
{
ACE_ERROR_RETURN((LM_ERROR,
"Script_Management_Service::register_name():\n" \
"\tException...\n"),
-1);
}
ACE_CATCHANY
{
ACE_PRINT_EXCEPTION(ACE_ANY_EXCEPTION,
"Script_Management_Service::register_name()\n");
return -1;
}
ACE_ENDTRY;
ACE_CHECK_RETURN(-1);
return 0;
}
--
I call the service in the server-class "manually":
--
...
command << "dynamic "
<< service_name
<< " Service_Object * ./Services/MARVIN_Services:_make_"
<< service_name
<< "() "
<< "\"" << parameter << "\"";
ACE_Service_Config *service_config = new
ACE_Service_Config("MARVIN_Server");
// Create an adapter to end the event loop.
ACE_Sig_Adapter sa ((ACE_Sig_Handler_Ex)
ACE_Reactor::end_event_loop);
ACE_Sig_Set sig_set;
sig_set.sig_add (SIGINT);
sig_set.sig_add (SIGQUIT);
// Register ourselves to receive signals so we can shut down
// gracefully.
if (ACE_Reactor::instance ()->register_handler (sig_set,
&sa) == -1)
{
ACE_DEBUG((LM_DEBUG, "(%p) Error while setting the
eventhandler.\n"));
}
result = service_config->process_directive(command->c_str());
ACE_Reactor::run_event_loop();
...
--
The server definitely crashes when the second Corba-call is made. The
client can wait for an arbitrary period of time before the second
Corba-call without crashing (or crashing the server or anything else).
The server(-process) which runs the service and the Corba-proxy of the
Script_Management crashes and I don't know why. If I use the
Script_Management-service and -Corba-proxy without letting the
Script_Management_CORBA_proxy call another Corba-object (i.e. another
server) it works like it should.
The call to a (Corba-)server in the Script_Management looks like this:
--
ACE_TRY_NEW_ENV
{
TAO_ORB_Manager orb_manager_;
TAO_Naming_Client naming_client_;
const char *orb_;
orb_ = "ORB";
DLL_ORB *orb =
ACE_Dynamic_Service<DLL_ORB>::instance (orb_);
if (orb == 0)
{
ACE_ERROR ((LM_ERROR,
"(%t) MARVIN_Script_Management::worker_thread():\n" \
"\tCan't find %s in the Service Repository\n",
orb_));
}
else
{
orb_manager_ = orb->orb_manager_;
if (naming_client_.init(orb->orb_manager_.orb()) != 0)
{
ACE_ERROR ((LM_ERROR,
"(%t) MARVIN_Script_Management::worker_thread():\n" \
"\tNo NameService found!\n"));
}
else
{
CosNaming::Name name;
name.length (1);
name[0].id = CORBA::string_dup ("server");
CORBA::Object_var server_object =
naming_client_->resolve (name);
MARVIN::Server_var server =
MARVIN::Server::_narrow (server_object.in());
server->start_Script(
new_Script_Descriptor->get_name().c_str(),
(CORBA::ULong)new_Script_Descriptor->get_id(),
(CORBA::ULong)new_Script_Descriptor->get_priority());
} /* if naming_client_ != 0 */
} /* if orb != 0 */
}
ACE_CATCHANY
{
ACE_PRINT_EXCEPTION (ACE_ANY_EXCEPTION,
"MARVIN_Script_Management::worker_thread()\n");
}
ACE_ENDTRY;
--
> I dont find anything amiss. That is regular path followed by a thread
> if a server closes connection (like crashing) when the client thread
> is waiting for the reply. It would be hard for us to help you without
> more detail about the problem!
I run a server with the svc.conf-file from my last email. A client
starts a service (Script_Mangement_Service) on the server (see above)
which activates a Corba-object (Script_Management_CORBA_proxy). After
that the client calls a method on this Corba-object. The first call
succeeds, every second call from this client on any other Corba-object
fails.
Hopefully I've provided you with sufficient information. Thanks for your
time and commitment.
Best regards,
Marco Wedekind
Balachandran Natarajan
On , 24 March, 2003 at 10:52:42 +0100, marco wrote:
[snipped]
> > Could you please explain what you mean by ACE_Service class?
> I've implemented the ACE_Service_Object like this:
Okay!
[snipped]
> The init()-method registers the Corba-proxy of the class
> Script_Management with the NameService and activates the
> Corba-proxy:
I get the idea, though I dont think we would be able to go through
every line of code and debug things...
[snipped]
>
> The server definitely crashes when the second Corba-call is made.
This is the first thing that you need to debug. You need to see why
the second call crashes the server. Please kickstart your favorite
memory checking tool and see why the server crashes. The client thread
throws a COMM_FAILURE since it lost its connection with the
server. Hence this is the root cause. Please debug this first.
> The client can wait for an arbitrary period of time before the
> second Corba-call without crashing (or crashing the server or
> anything else).
I dont get exactly what you mean here. But I assume you seem to feel
that the server crash is not connected to second CORBA call. I doubt
that. I feel that the second CORBA call is the culprit that crashes
the server and hence the client reacts the way it is expected to.
> The server(-process) which runs the service and the Corba-proxy of the
> Script_Management crashes and I don't know why. If I use the
> Script_Management-service and -Corba-proxy without letting the
> Script_Management_CORBA_proxy call another Corba-object (i.e. another
> server) it works like it should.
>
> The call to a (Corba-)server in the Script_Management looks like this:
[snipped]
> Hopefully I've provided you with sufficient information. Thanks for your
> time and commitment.
I have tried giving you sufficient directions for investigating your
application. Hopefully that will help you to track down the
problem. If you need more help debugging your application, I would
recommend talking to one of the commercial support companies listed in
http://www.cs.wustl.edu/~schmidt/commercial-support.html
Thanks very much!
Regards
Bala
Steve Totten
>I just thought, that there could be a list of known reasons why a second
>Corba-call fails generally.
>
One possibility is that some memory in your server is being
freed during or after the first invocation that is needed for
the second and subsequent invocations. So, when the second
invocation is being processed, an attempt to access that freed
memory results in a segmentation violation.
Try building and running your application with a memory-checking
tool such as Purify. Also, review the OMG IDL-to-C++ mapping's
memory management rules. They are well covered in the book
"Advanced CORBA Programming with C++" by Michi Henning and Steve
Vinoski.
HTH,
Steve
--
----------------------------------------------------------------
Steve Totten, Principal Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------------------
marco
please excuse me for answering so late but I'm in the middle of my exam
preparations so I only found little time for debugging :(
> One possibility is that some memory in your server is being
> freed during or after the first invocation that is needed for
> the second and subsequent invocations. So, when the second
> invocation is being processed, an attempt to access that freed
> memory results in a segmentation violation.
> Try building and running your application with a memory-checking
> tool such as Purify. Also, review the OMG IDL-to-C++ mapping's
> memory management rules. They are well covered in the book
> "Advanced CORBA Programming with C++" by Michi Henning and Steve
> Vinoski.
I've used the free software mpatrol to debug the memory problem. Please see
the log-file below. There are two errors of which the second one causes the
serverprocess to exit.
The second error "ERROR: [ILLMEM]: illegal memory access at address
0x55555555" is described by the mpatrol manual as follows:
`ILLMEM'
Message `illegal memory access at address %1'
Type Error
`%1' The address at which the illegal memory access occurred.
Cause An attempt was made to read from or write to an illegal address on
systems which have virtual memory. This address may or may not exist in
the heap, or it may be a perfectly valid address that was misaligned and
caused a bus error. In either case, the mpatrol library will attempt to
associate the address with an existing memory allocation. This error may
also appear instead of memory corruption errors if the `PAGEALLOC' or
`OFLOWWATCH' options were used.
Additional The library summary, information about the original memory
allocation (if possible) and the call stack of where the error occurred.
Result Execution terminates.
Is it possible for you to decide from the below log-file wether this error is
to be found on "my side" or if it's a ACE/TAO-error? It seems that the error
occurs in an ACE/TAO-function, but I don't see from the below logfile, what I
could do against it.
Thanks Marco
--- mpatrol.log ---
@(#) mpatrol 1.4.8 (02/01/08)
Copyright (C) 1997-2002 Graeme S. Roy
This is free software, and you are welcome to redistribute it under certain
conditions; see the GNU Library General Public License for details.
For the latest mpatrol release and documentation,
visit http://www.cbmamiga.demon.co.uk/mpatrol.
operating system: UNIX
system variant: Linux
processor architecture: Intel 80x86
processor word size: 32-bit
object file format: BFD
dynamic linker type: SVR4
Log file generated on Thu Apr 24 14:16:08 2003
read 387 symbols from /usr/local/lib/libmpatrolmt.so
read 831 symbols from /usr/lib/libbfd.so
read 342 symbols from /usr/local/binutils-2.13.1/libiberty/libiberty.so
read 345 symbols from /usr/lib/libpthread.so
read 1250 symbols from /usr/lib/libg++-libc6.2-2.so.3
read 5946 symbols from /opt/ACE_wrappers/ace/libTAO.so.1.3.0
read 1475 symbols from /opt/ACE_wrappers/ace/libTAO_CosNaming.so.1.3.0
read 59 symbols from /opt/ACE_wrappers/ace/libTAO_Svc_Utils.so.1.3.0
read 200 symbols from /opt/ACE_wrappers/ace/libTAO_IORTable.so.1.3.0
read 3838 symbols from /opt/ACE_wrappers/ace/libTAO_PortableServer.so.1.3.0
read 824 symbols from ./Services/libMARVIN_Services.so.1.3.0
read 4661 symbols from /opt/ACE_wrappers/ace/libACE.so.5.3.0
read 37 symbols from /lib/libdl.so.2
read 102 symbols from /lib/librt.so.1
read 1172 symbols from /usr/lib/libstdc++-libc6.2-2.so.3
read 963 symbols from /lib/libm.so.6
read 4122 symbols from /lib/libc.so.6
read 233 symbols from /lib/ld-linux.so.2
read 798 symbols from ./server
FREE: operator delete[] (0x0809B0C9) [1026|-|-|-]
0x40279DE6 _._16CORBA_String_var+38
0x0807A33B get_info_skel__Q210POA_MARVIN6ServerR17TAO_ServerRequestPvT2+555
0x40766DB5
synchronous_upcall_dispatch__15TAO_ServantBaseR17TAO_ServerRequestPvT2+261
0x0807C583 _dispatch__Q210POA_MARVIN6ServerR17TAO_ServerRequestPv+35
0x4075BABF
dispatch__18TAO_Object_AdapterR13TAO_ObjectKeyR17TAO_ServerRequestG16CORBA_Object_out+335
0x40337EA5
dispatch__20TAO_Adapter_RegistryR13TAO_ObjectKeyR17TAO_ServerRequestG16CORBA_Object_out+69
0x4034FB66
dispatch__22TAO_Request_DispatcherP12TAO_ORB_CoreR17TAO_ServerRequestG16CORBA_Object_out+86
0x40359D52
process_request__21TAO_GIOP_Message_BaseP13TAO_TransportR12TAO_InputCDRR13TAO_OutputCDRP33TAO_GIOP_Message_Generator_Parser+354
0x403595A5
process_request_message__21TAO_GIOP_Message_BaseP13TAO_TransportP15TAO_Queued_Data+549
0x4023DCEB
process_parsed_messages__13TAO_TransportP15TAO_Queued_DataR17TAO_Resume_Handle+219
0x4023D0F1
handle_input_i__13TAO_TransportR17TAO_Resume_HandleP14ACE_Time_Valuei+1041
0x40243B57 handle_input_eh__22TAO_Connection_HandleriP17ACE_Event_Handler+679
0x40252B17 handle_input__27TAO_IIOP_Connection_Handleri+39
0x409F8B4F dispatch_socket_event__14ACE_TP_ReactorR20ACE_EH_Dispatch_Info+127
0x409F7D52 handle_socket_events__14ACE_TP_ReactorRiR18ACE_TP_Token_Guard+178
0x409F8A7A
dispatch_i__14ACE_TP_ReactorP14ACE_Time_ValueR18ACE_TP_Token_Guard+138
0x409F73D1 handle_events__14ACE_TP_ReactorP14ACE_Time_Value+529
0x40A58F57 handle_events__11ACE_ReactorP14ACE_Time_Value+55
0x40300F83 run__12TAO_ORB_CoreP14ACE_Time_Valuei+451
0x4029EBC3 run__9CORBA_ORBP14ACE_Time_Value+51
0x4029EB51 run__9CORBA_ORB+33
0x4076F69F run__15TAO_ORB_Manager+63
0x408C237F svc__7DLL_ORB+111
0x40A2D62C svc_run__13ACE_Task_BasePv+76
0x409E9176 invoke_i__18ACE_Thread_Adapter+86
0x409E8F7D invoke__18ACE_Thread_Adapter+125
0x409B1D72 ace_thread_adapter+34
0x400D0E67 pthread_start_thread+251
0x40C7372A thread_start+4
ERROR: [NOTALL]: operator delete[]: 0x0809B0C9 has not been allocated
system page size: 4096 bytes
default alignment: 4 bytes
overflow size: 0 bytes
overflow byte: 0xAA
allocation byte: 0xFF
free byte: 0x55
allocation stop: 0
reallocation stop: 0
free stop: 0
unfreed abort: 0
small boundary: 32 bytes
medium boundary: 256 bytes
large boundary: 2048 bytes
lower check range: 0
upper check range: 0
check frequency: 1
failure frequency: 0
failure seed: 1051186568
prologue function: <unset>
epilogue function: <unset>
handler function: <unset>
log file: mpatrol.5676.log
profiling file: mpatrol.5676.out
tracing file: mpatrol.5676.trace
program filename: ./server
symbols read: 27585
autosave count: 0
freed queue size: 0
allocation count: 1941
allocation peak: 1206 (1211725 bytes)
allocation limit: 0 bytes
allocated blocks: 1115 (482110 bytes)
marked blocks: 0 (0 bytes)
freed blocks: 0 (0 bytes)
free blocks: 198 (849090 bytes)
internal blocks: 204 (3342336 bytes)
total heap usage: 4673536 bytes
total compared: 93 bytes
total located: 278 bytes
total copied: 159636 bytes
total set: 2523756 bytes
total warnings: 0
total errors: 1
ERROR: [ILLMEM]: illegal memory access at address 0x55555555
0x55555555 not in heap
call stack
0x40BCAA38 __restore
0x4075D7DF
prepare_for_upcall__Q218TAO_Object_Adapter14Servant_UpcallRC13TAO_ObjectKeyPCcG16CORBA_Object_out+271
0x4075BA75
dispatch__18TAO_Object_AdapterR13TAO_ObjectKeyR17TAO_ServerRequestG16CORBA_Object_out+261
0x40337EA5
dispatch__20TAO_Adapter_RegistryR13TAO_ObjectKeyR17TAO_ServerRequestG16CORBA_Object_out+69
0x4034FB66
dispatch__22TAO_Request_DispatcherP12TAO_ORB_CoreR17TAO_ServerRequestG16CORBA_Object_out+86
0x40359D52
process_request__21TAO_GIOP_Message_BaseP13TAO_TransportR12TAO_InputCDRR13TAO_OutputCDRP33TAO_GIOP_Message_Generator_Parser+354
0x403595A5
process_request_message__21TAO_GIOP_Message_BaseP13TAO_TransportP15TAO_Queued_Data+549
0x4023DCEB
process_parsed_messages__13TAO_TransportP15TAO_Queued_DataR17TAO_Resume_Handle+219
0x4023D0F1
handle_input_i__13TAO_TransportR17TAO_Resume_HandleP14ACE_Time_Valuei+1041
0x40243B57 handle_input_eh__22TAO_Connection_HandleriP17ACE_Event_Handler+679
0x40252B17 handle_input__27TAO_IIOP_Connection_Handleri+39
0x409F8B4F dispatch_socket_event__14ACE_TP_ReactorR20ACE_EH_Dispatch_Info+127
0x409F7D52 handle_socket_events__14ACE_TP_ReactorRiR18ACE_TP_Token_Guard+178
0x409F8A7A
dispatch_i__14ACE_TP_ReactorP14ACE_Time_ValueR18ACE_TP_Token_Guard+138
0x409F73D1 handle_events__14ACE_TP_ReactorP14ACE_Time_Value+529
0x40A58F57 handle_events__11ACE_ReactorP14ACE_Time_Value+55
0x40300F83 run__12TAO_ORB_CoreP14ACE_Time_Valuei+451
0x4029EBC3 run__9CORBA_ORBP14ACE_Time_Value+51
0x4029EB51 run__9CORBA_ORB+33
0x4076F69F run__15TAO_ORB_Manager+63
0x0808526E run__21MARVIN_Server_Manager+62
0x08085488 main+376
0x40BB99ED __libc_start_main+189
0x08067921 _start+33
--- End of mpatrol.log ---
Steve Totten
marco wrote:
> please excuse me for answering so late but I'm in the middle of my exam
> preparations so I only found little time for debugging :(
No problem. Good luck with your exams!
>>One possibility is that some memory in your server is being
>>freed during or after the first invocation that is needed for
>>the second and subsequent invocations. So, when the second
>>invocation is being processed, an attempt to access that freed
>>memory results in a segmentation violation.
>
>
>>Try building and running your application with a memory-checking
>>tool such as Purify. Also, review the OMG IDL-to-C++ mapping's
>>memory management rules. They are well covered in the book
>>"Advanced CORBA Programming with C++" by Michi Henning and Steve
>>Vinoski.
>
>
> I've used the free software mpatrol to debug the memory problem. Please see
> the log-file below. There are two errors of which the second one causes the
> serverprocess to exit
>
> The second error "ERROR: [ILLMEM]: illegal memory access at address
> 0x55555555" is described by the mpatrol manual as follows:
Hmmm... That address (0x55555555) seems fishy.
It has the look of a special "marker" of sorts.
Some debuggers and memory-checking tools automatically fill
newly-allocated or just-freed memory with special values like
this to make them easily recognizable. Can you check to see
if mpatrol does something like this?
> `ILLMEM'
> Message `illegal memory access at address %1'
> Type Error
> `%1' The address at which the illegal memory access occurred.
> Cause An attempt was made to read from or write to an illegal address on
> systems which have virtual memory. This address may or may not exist in
> the heap, or it may be a perfectly valid address that was misaligned and
> caused a bus error. In either case, the mpatrol library will attempt to
> associate the address with an existing memory allocation. This error may
> also appear instead of memory corruption errors if the `PAGEALLOC' or
> `OFLOWWATCH' options were used.
> Additional The library summary, information about the original memory
> allocation (if possible) and the call stack of where the error occurred.
> Result Execution terminates.
>
> Is it possible for you to decide from the below log-file wether this error is
> to be found on "my side" or if it's a ACE/TAO-error? It seems that the error
> occurs in an ACE/TAO-function, but I don't see from the below logfile, what I
> could do against it.
Just because an error occurs in an ACE/TAO function does not
necessarily mean it is an ACE/TAO error. TAO (CORBA) is a
framework that makes calls into user code. As such, it makes
certain assumptions about what the user code does. For example,
the framework may hold pointers to user-allocated memory.
Later, it expects to be able to use those pointers. If the
user has freed the memory, an access violation will occur. The
violation occurs in framework code, but the error was the user's.
Does that make sense?
That is why it is so important to understand the memory management
responsibilities imposed upon the programmer by the IDL-to-C++
language mapping.
[snip]
It looks like the server is handling an incoming request and
preparing to make an upcall onto a servant. This is an example
of where the framework (the POA in this case) holds a pointer to
user-allocated memory (a servant object in this case). It may be
that the servant has already been destroyed, or that a bad pointer
was passed to the POA when the servant was activated (though that
seems unlikely since the POA would have used that pointer to
invoke _add_ref() on the servant at activation time).
Can you send the code in your server where you are creating and
activating the servant with the POA?
marco
On Tuesday, 29. April 2003 21:02 you wrote:
> Hmmm... That address (0x55555555) seems fishy.
> It has the look of a special "marker" of sorts.
> Some debuggers and memory-checking tools automatically fill
> newly-allocated or just-freed memory with special values like
> this to make them easily recognizable. Can you check to see
> if mpatrol does something like this?
I can't find anything about this in the manual...
> Just because an error occurs in an ACE/TAO function does not
> necessarily mean it is an ACE/TAO error. TAO (CORBA) is a
> framework that makes calls into user code. As such, it makes
> certain assumptions about what the user code does. For example,
> the framework may hold pointers to user-allocated memory.
> Later, it expects to be able to use those pointers. If the
> user has freed the memory, an access violation will occur. The
> violation occurs in framework code, but the error was the user's.
> Does that make sense?
Yes, that's clear. I just don't find the point where my application fails :(
> That is why it is so important to understand the memory management
> responsibilities imposed upon the programmer by the IDL-to-C++
> language mapping.
>
> [snip]
> It looks like the server is handling an incoming request and
> preparing to make an upcall onto a servant. This is an example
> of where the framework (the POA in this case) holds a pointer to
> user-allocated memory (a servant object in this case). It may be
> that the servant has already been destroyed, or that a bad pointer
> was passed to the POA when the servant was activated (though that
> seems unlikely since the POA would have used that pointer to
> invoke _add_ref() on the servant at activation time).
>
> Can you send the code in your server where you are creating and
> activating the servant with the POA?
Ok, here it is:
--- Server_Manager.h ----------------------
protected:
MARVIN_Server_i server_; //that's the Corba-Object which inherits from
//POA_MARVIN::Server
----------------------------------------------------
--- Server_Manager.cpp --------------------
int MARVIN_Server_Manager::init(const char *servant_name,
int argc,
char *argv[])
{
ACE_TRY_NEW_ENV
{
...
DLL_ORB *orb =
ACE_Dynamic_Service<DLL_ORB>::instance (this->orb_);
...
this->orb_manager_ = orb->orb_manager_;
if (this->orb_manager_.init_child_poa(argc,
argv,
servant_name) == -1)
{
ACE_ERROR_RETURN ((LM_ERROR,
"%p\n",
"MARVIN_Server_Manager::init()\n"),
-1);
}
ACE_CHECK_RETURN (-1);
if (this->orb_manager_.activate_under_child_poa(
"MARVIN_Server",
&this->server_) == 0)
{
ACE_ERROR_RETURN ((LM_ERROR,
"%p\n",
"MARVIN_Server_Manager::init()\n"),
-1);
}
...
} /* end of init */
---------------------------------------------------
I hope you can see something in the code that looks like the error.
Thanks,
Marco