Conference turris::decladebug

841.0. "Simple case showing show-stopper dxladebug problems" by ADA9X::BRETT () Fri Feb 14 1997 12:20

Here is a simple test case that illustrates some big frustrations that the
C++ team currently has with dxladebug.  The net effect of these bugs is that
the GUI is simply unusable for most of our purposes.

/Bevin



The program is made up of the files given at the end.


To compile and link them, do

    cxx -g eg024*.c{,xx}

Now, here is the script showing all the things that go wrong.

    dxladebug a.out &


1.  RERUN looses the command line
*********************************
 
    (ladebug) run one-parameter; cont; rerun; cont

    	Notice that it prints out
    	    argc = 2
    	    argc = 1
    	In other words, even when given only (ladebug) commands rerun
    	drops the command line!

    Unfortunately, in our case, this causes the program to start reading from
    stdin, which hangs dxladebug.


2.  RERUN looses the command line when done using mouse too!
************************************************************

    Now use the FILE RUN-NEW menu and the RERUN button

    	same problem as 1


3.  The BROWSE SOURCE view can't set breakpoints in many cases
**************************************************************

    FILE menu
    BROWSE SOURCES
    double-click a.out
    double-click eg024b.cxx
    click p1(int)
    click SET BREAKPOINT

    	Can't set breakpoint in routine p1(int)

    because it has still got the engine in lang="C" mode, but we
    are trying to set a breakpoint on a C++ function.


4.  The BREAKPOINT buttons are simply missing in some cases
**************************************************************

    We have modules that are thousands of lines long with this problem.
 
    (ladebug) stop in p2; run; cont

    	The breakpoint buttons are missing

    The module is an include file containing both declarations and
    complete functions.  This style is used by both us and EDG.


--------------------------------------------------------------------------------
cat > eg024.h

//begin eg024.h
int p1(int depth);
//end eg024.h


cat > eg024.hxx

//begin eg024.hxx
extern "C" {
#include "eg024.h"
}
int p2(int depth);
//end eg024.hxx


cat > eg024a.c

//begin eg024a.c
#include "eg024.h"

int main(int argc, char **argv) {
    printf("argc = %d\n",argc);
    p1(5);
    return 0;
}
//end eg024a.c


cat > eg024b.cxx

//begin eg024b.cxx
#include "eg024.hxx"

int p1(int depth)
{
    return (depth<=0) ? 1 : p2(depth-1);   
}
//end eg024b.cxx


cat > eg024c.cxx

//begin eg024c.cxx
#include "eg024.hxx"
enum {E=1};

#include "eg024c.inc"
//end eg024c.cxx


cat > eg024c.inc

//begin eg024c.inc
typedef void* void_ptr;	    void_ptr void_ptr_use;

typedef struct some_struct {
    struct some_struct* 	        next;
} some_struct;

struct some_struct some_struct_use;

int p2(int depth) {
    void_ptr_use = 0;
    return p1(depth) + E;
}
//end eg024c.inc

I've reproduced problems 1 through 3.  They are on our list.

Problem 4 needs more analysis.  Someone will report back here on that.
At first glance it appears to be similar to 811.*

-Chris

    
    
    It is not clear whether the RERUN problems reported in the base note 
    are directly related to the RERUN problems reported in note 646 or
    not, but if someone is going to be working on RERUN soon, it may be
    helpful to be aware of all such similar problems while doing the work.
    
    
    Bob
    

A workaround for problem #3 is to do this in the command window:

	(ladebug) set $lang="C++"

and then set the breakpoint again in the source browser window.

-Chris

Fantastic!!!!

/Bevin

see 884 for the last critical issue - number (4)

/Bevin

This problem from .0 is fixed in 4.0-36:


    3.  The BROWSE SOURCE view can't set breakpoints in many cases
    **************************************************************

	FILE menu
	BROWSE SOURCES
	double-click a.out
	double-click eg024b.cxx
	click p1(int)
	click SET BREAKPOINT

	    Can't set breakpoint in routine p1(int)

	because it has still got the engine in lang="C" mode, but we
	are trying to set a breakpoint on a C++ function.

4.0-BL36 results
----------------

1.
==

(ladebug) run one-parameter; cont; rerun; cont

	This gets the right answer, *BUT* then gets 
	Unhandled DBGAPI_Exception, text: EXCEPTION:

If you then give the command again, the debugger exits unexpectedly and the
GUI freezes.

This doesn't happen when you issue the commands one at a time rather than
in a comma list.



2.
==

As noted elsewhere, FILE RUN-NEW menu does keep the args, but doesn't
show them in the box


3.
==

This is fixed.  Unfortunately there is another even worse behaviour
although I haven't determined if the following is a regression or was
always there...

    FILE menu
    BROWSE SOURCES
    double-click a.out
    double-click eg024b.cxx
    click p1(int)
    click SET BREAKPOINT
    double-click eg024a.c

The GUI gets a strange prompt, and doesn't expand the menu.
Some of the buttons stay live.  Clicking them some things to work, some things
not to, and fairly soon...

% dxladebug : Fatal internal error detected
Caught unexpected signal "Segmentation fault", exiting ...


4.
==

Now has bpt buttons


/Bevin


4.
==