Conference caldec::wrl_atom

This note is cross-posted in the DCE notesfile, note 2152 !!!

This reply belongs to the former ones of Mr. Stuckmann and includes a detailed
description of the problems we have:

[Recall]
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.
[End Recall]

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

When atomizing (third degree 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

Thank you for the example code. That will be a useful test case,
when we come to look into the problem.

However, I have not seen mention of any attempt to follow the
suggestions I have made in my previous replies; for example:

  I suggest you take another look at my reply .1 and try some of
  the other things I suggested, like increasing the threads'
  stack sizes and looking in the .3log file for evidence of
  the program using uninitialized or invalid memory.

If you just continue telling me that Third Degree makes your
program crash, I can only continue telling you that Third Degree
is designed to make faulty programs crash and otherwise malfunction.
 
We do not have spare cycles right now, to look into this apparently 
complex problem (DCE not being a core skill in the Atom team), but if 
you enter a QAR with an appropriate severity, we can work it into our
schedule. Alternatively, I can enter the QAR for you, based on
your notes reply 283.5, with a High priority.

If you need an immediate solution, you could try Insure++ from
Parasoft (see http://www.parasoft.com/ ), which is available on
Alpha, though I'm not sure which versions. There is also the
Final Exam Memory Advisor from Platinum Technology. I can't
find any info in their home page http://www.platinum.com/
but this page (found via an AltaVista search for "Memory Advisor")
http://www.esoft.co.uk/products/Platinum/memadvise.html does
show that it is available for Digital UNIX V3.x.

John,

	We already tested some of the proposals you made in .1.
Increasing the stack size didn't make a big difference - the program crashed
somewhat different, but not in a way that we were able to derive any
systematic dependency. 

	Analyzing the .3log file didn't help a lot either - since we stripped
of all of our application code, we were deeply inside RPC when interpreting
this file. 

	From the DCE guys we got the answer that they used ATOM with their DCE
implementation and it worked/didn't work depending on the ATOM version they
used. 
	So far we are running out of ideas where to continue. 

With this in mind, I appreciate very much your proposal to enter the QAR for
us. Let me know if you need any background for a formal escalation (I could
send you some additional information about project size, time schedule etc.) 

Thanks in advance

 Hermann 

	(Hermann Konrad, PATIS Engineering, Munich/Germany)

I have entered QAR number 51465 in the OSF_QAR database on node GORGE::
(copying note 283.5).

I have also entered note 2152.2 in the TUXEDO::DCE-PRODUCTS conference,
requesting that I or you get a non-stripped, debuggable version of DCE
v2.0a to let us get some meaningful stack traces. If we can get this,
I will suggest to you that you use it in an attempt to make sense of
the .3log error reports. You should also compile your own application
with the -g flag; indeed, this is called out at the very start of the
Third Degree man-page, so I suggest that you read the man-page again.

Another suggestion I made earlier is that you try using an earlier
version of Atom and Third Degree. In particular, you might find it
helpful to de-install the ADK completely and reinstall the CMPLRS and
PGMR subsets from the Digital UNIX V4.0A kit. That version of Third Degree
is quite stable, and its -Xgprog option works correctly, which will help
you use dbx or ladebug (try the newest version 4.0-30 if the version on the kit
is not useable) to examine what happens at the point of the stack overflow.

A new idea is to use Third Degree's .third options-file to select
appropriate options for your testing. I realized that I don't know why
you are using Third Degree. Are you looking for:

	(1) Code that reads uninitialized memory?

	(2) Memory Leaks?

	(3) Memory Usage?

If you are not looking for (1), then you can enter the following commands
in a ./.third file:

	uninit_heap no
	uninit_stack no

Doing this is likely to avoid the problem you are seeing, but you will
still get a report of memory leaks.

Similarly, you can  enter "no leaks at_exit" to disable the leak checking,
or you can enter one of the "all ..." or "new ..." commands to get more
information. Again, read the man-page third(5) for details.

In any case, please tell me what you are trying to use Third Degree for,
and the results of the above suggestions. We will not be starting to
investigate the QAR until you have exhausted all options described in
the man page and we have heard of the availability of a debuggable DCE kit.
Apart from anything else, we do not have time right now.