[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference tuxedo::dce-products

Title:DCE Product Information
Notice:Kit Info - See 2.*-4.*
Moderator:TUXEDO::MAZZAFERRO
Created:Fri Jun 26 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2269
Total number of notes:10003

2152.0. "Problems with DCE and ATOM" by BHAJEE::AIGNER () Thu Feb 06 1997 09:53

This note is cross-posted in the ATOM notesfile, note 283 !!!



We are developing a complex client/server system on Digital Unix 4.0a
with DCE 2.0a (Rev. 515) and DEC C++ 5.5.
For program analysis we want to use Atom V2.29  December 3, 1996,
especially 'third'.

We've got trouble when atomizing server applications.
There are NO problems with the non-atomized server versions.

To show the problem I reduced one server to the simplest version
possible.

When atomizing (third tool of ATOM) this simple RPC server implementation
and run the atomized exe, I get a stack overflow:

$ server.third
Stack overflow: pid 2310, proc server.third, addr 0x3ad2d140516e70, pc 0x3ff8087
70b8
Memory fault(coredump)

This only happens when the named object is registered BEFORE the
rpc_server_listen call.
When registering the named object AFTER the listen call all works
fine.

All the necessary sources to reproduce the situation follow.

The same problem arises with another server implementation I'll
describe after the source listing:

******************************************************************
* ifclass.idl (Interface decl. for RPC class MyRpcNamedClass)
******************************************************************

[
 uuid(f902b1e5-7b70-11d0-b987-08002be5fa99)
]
interface MyRpcNamedClass
{
    void foo ([in] int n);
}

******************************************************************
* server.cxx (version without thread; register before listen)
******************************************************************

#include <dce/rpc.h>
#include <iostream.h>
#include "ifclass_mgr.h"

main()
{
    unsigned status = 0;
    MyRpcNamedClassMgr* rpcNamedObj_p;

    rpc_server_use_protseq((unsigned_char_t*) "ncacn_ip_tcp",
                           rpc_c_protseq_max_calls_default, &status);

    rpcNamedObj_p = new MyRpcNamedClassMgr();
    rpcNamedObj_p->register_named_object((unsigned_char_t*) "/.:/MyRpcObject");

    rpc_server_listen(rpc_c_listen_max_calls_default, &status);
}

******************************************************************
* build (to create the atomized server)
******************************************************************

idl -standard extended -lang cxx ifclass.idl

cxx -c -threads -I/usr/include -I. server.cxx

cxx -threads -o server server.o ifclass_sstub.o -ldce -lidlcxx

atom server -tool third -all -env threads -o server.third

******************************************************************


-------
Case 2:|
-------

I get the same error when I invoke rpc_server_listen in an own thread.
In this case it is irrelevant when registering the named object.
The atomized server crashes in both cases.
The listing of this server implementation follows:

******************************************************************
* server.cxx (version with thread)
******************************************************************

#include <dce/rpc.h>
#include <iostream.h>
#include "ifclass_mgr.h"

static void* listenFunction(void*)
{
    unsigned status = 0;
    rpc_server_listen(rpc_c_listen_max_calls_default, &status);
    return NULL;
}

main()
{
    unsigned status = 0;
    char command = ' ';
    MyRpcNamedClassMgr* rpcNamedObj_p;

    rpc_server_use_protseq((unsigned char*) "ncacn_ip_tcp",
                           rpc_c_protseq_max_calls_default,
                           &status);

    pthread_t listenThread;
    pthread_attr_t threadAttr;

    pthread_attr_create(&threadAttr);
    pthread_create(&listenThread,
                   threadAttr,
                   &listenFunction,
                   NULL
                   );

    rpcNamedObj_p = new MyRpcNamedClassMgr();
    rpcNamedObj_p->register_named_object((unsigned_char_t*) "/.:/MyRpcObject");

    // Waiting
    cin >> command;
}

*****************************************************************

Since I think the example code is simple and lacks user errors,
there might be a problem in ATOM or DCE or in the coexistence of both.

If there is no problem solution, we cannot use ATOM for server
applications within our project.

Hopefully someone can help me.

Thanks in advance
Helmut

T.RTitleUserPersonal
Name
DateLines
2152.1check with ATOM, UNIX groupsTUXEDO::ZEEThere you go.Thu Feb 06 1997 14:467
FYI, I've successfully used atom V2.24 to analyze cdsd, which is
slightly more complicated than your example program ;^)  Previous
versions of atom were hit and miss, and I haven't tried V2.29.
You might need to boost some kernel parameter, but I don't believe
we can help much here.

--Roger
2152.2non-stripped, debuggable DCE kit please...SMURF::JPWJohn P Williams, DUDE, USG, 381-2079Tue Feb 11 1997 09:4518
Hi,

I'm the Atom team leader, so I'm looking into the difficulties reported
in the base note.

It sounds like DCE is shipped stripped, which makes it impossible for
Third Degree to print much in the way of a stack trace in its error logs.
For maximum information, full debug symbol information (ie with DCE and the
application compiled -g) is needed too.

So, can I (or the base note author) get a non-stripped, debuggable DCE kit 
or the equivalent set of library files? That might let us figure out what's
happening. The application is apparently running on Digital UNIX V4.0A with
DCE 2.0a (Rev. 515), so this is the version we need debuggable libraries for.
Send me mail.

	Thanks
		John P Williams, Digital UNIX Development Environment Group
2152.3I'll send you and the base author mail containing pointerTUXEDO::ZEEThere you go.Tue Feb 11 1997 16:390