[comp.unix.ultrix] DS3100: buggy cc

jonasn@ttds.UUCP (Jonas Nygren) (06/03/89)

I have seen no comments so far on the DS3100's C-compiler. I am having
lots of problems with especially pointers changing value in the middle
of a loop (there are no redundant if-statements as warned for in the 
'Release Notes for RISC processors') and the last thing that happened
is :
(dbx) r
[2] stopped at [arrow_down_button:390 ,0x402694]        arrow_button2 (self, arr
ow_down_fill,DOWN);
(dbx) n
[arrow_down_button:391 ,0x4026a8]       }
(dbx) n

Segmentation fault [arrow_down_button:391 +0x10,0x4026b8]
        }
(dbx) l 387:5
   387  arrow_down_button (self)
   388  sbarwindata * self;
   389  {
   390      arrow_button2 (self, arrow_down_fill,DOWN);
>* 391  }
(dbx)

it bombs on exit of the function. I don't do any fancy stack-fiddling,
just vanilla C, so don't blame me :-). The function is called via:

	(*object->func)(object)

I have had numerous bugs which I haven't bothered to identify, often it
will help to introduce a global temporary variable to hold the value
and in other cases it has helped to reshuffle the code. Significant is
that in all cases its pointer-values that has been affected.

My problem is that I can't figure out how to work-around these problems. 
Has anyone encountered similar problems with 'cc' on the PMAX?  Other
problems? Do you know any workarounds?

Have Digital indicated when the cc2.0 release will be available?

Yes, I have reported my problems to service but I write to the net
with a hope of speedier relief.

Jonas

Please mail responses to  jonas@softix.se  if possible.

jonasn@ttds.UUCP (Jonas Nygren) (06/06/89)

I have not got any responses on my query yet and my problem remains. In the
meantime I have been able to extract the essence of the bug and put it into a
small example which is included below. What can possibly go wrong??? 

When prog, below, is run this is the result.

% prog
Segmentation fault (core dumped)
%

Why does XNextEvent overwrite yyy's return adress on the stack??? 

Any help is welcome.
Thanx in advance


---------------- Compile: cc -g2 prog.c -o prog -lX11

#include <X11/Xlib.h>

Display *display;
Screen *screen;
int screen_no;
Window rootwin;
typedef unsigned long   color;
color black,white;


yyy()
{
	do_nextevent();
}

main(){
	Window w;

	display = XOpenDisplay ("");
	screen = XDefaultScreenOfDisplay (display);
	screen_no = XDefaultScreen(display);
	rootwin = XDefaultRootWindow (display);
	black = XBlackPixelOfScreen (screen);
	white = XWhitePixelOfScreen (screen);

	w = XCreateSimpleWindow(display, rootwin,
				100, 100, 300, 300, 0, black, white);
	XSelectInput(display,w,ExposureMask);
	XMapRaised(display,w);

	yyy();

	XDestroyWindow(display,w);
	XCloseDisplay(display);
}

do_nextevent()
{
	XAnyEvent e;

	XNextEvent(display, &e);
}

thomas@mipsbx.nac.dec.com (Matt Thomas) (06/06/89)

> I have not got any responses on my query yet and my problem remains. In the
> meantime I have been able to extract the essence of the bug and put it into a
> small example which is included below. What can possibly go wrong??? 

You have a bug in your program.

>[most of progam deleted]
>
> do_nextevent()
> {
> 	XAnyEvent e;
> 
> 	XNextEvent(display, &e);
> }

XNextEvent takes a pointer to a XEvent as the second parameter, not a 
pointer to XAnyEvent.  The structure XAnyEvent is smaller than XEvent
so when XNextEvent copies the event into *e, part fo the stack is over-
written causing the segmentation fault.

Changing XAnyEvent e to XEvent e will make the program work correctly.

-- 
Matt Thomas                     Internet:   thomas@decwrl.dec.com
DECnet-Ultrix Development       UUCP:       ...!decwrl!thomas
Digital Equipment Corporation   Disclaimer: This message reflects my own
Littleton, MA                               warped views, etc.

dik@cwi.nl (Dik T. Winter) (06/07/89)

(I am not able to reply, hence a followup)

In article <1211@ttds.UUCP> jonasn@ttds.UUCP (Jonas Nygren) writes:
 > do_nextevent()
 > {
 > 	XAnyEvent e;
 > 
 > 	XNextEvent(display, &e);
 > }

Perusing the X sources reveals that the second parameter of XNextEvent
is not of type *XAnyEvent but of type *XEvent (which is a union of
all kinds of events).  Probably an XEvent is larger than an XAnyEvent,
so XNextEvent will scribble somewhat on the stack, and all kind of
things may happen.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax
From dik@boring.cwi.nl  Wed Jun  7 01:26:13 1989
Received: by boring.cwi.nl via EUnet; Wed, 7 Jun 89 01:26:13 +0200 (MET)
Date: Wed, 7 Jun 89 01:26:13 +0200
From: dik@boring.cwi.nl (Dik T. Winter)
Message-Id: <8906062326.AA01677@boring.cwi.nl>
To: draken!ttds!jonasn@kth.uucp
Subject: Re: DS3100: buggy cc
Newsgroups: comp.unix.ultrix
In-Reply-To: <1211@ttds.UUCP>
References: <1207@ttds.UUCP>
Organization: CWI, Amsterdam

In article <1211@ttds.UUCP> you write:
 > do_nextevent()
 > {
 > 	XAnyEvent e;
 > 
 > 	XNextEvent(display, &e);
 > }

Perusing the X sources reveals that the second parameter of XNextEvent
is not of type *XAnyEvent but of type *XEvent (which is a union of
all kinds of events).  Probably an XEvent is larger than an XAnyEvent,
so XNextEvent will scribble somewhat on the stack, and all kind of
things may happen.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

To: jonasn@ttds.UUCP
Subject: Re: DS3100: buggy cc
Newsgroups: comp.unix.ultrix
In-Reply-To: <1211@ttds.UUCP>
References: <1207@ttds.UUCP>
Organization: CWI, Amsterdam

In article <1211@ttds.UUCP> you write:
 > do_nextevent()
 > {
 > 	XAnyEvent e;
 > 
 > 	XNextEvent(display, &e);
 > }

Perusing the X sources reveals that the second parameter of XNextEvent
is not of type *XAnyEvent but of type *XEvent (which is a union of
all kinds of events).  Probably an XEvent is larger than an XAnyEvent,
so XNextEvent will scribble somewhat on the stack, and all kind of
things may happen.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

To: mcvax!kth!draken!ttds!jonasn
Subject: Re: DS3100: buggy cc
Newsgroups: comp.unix.ultrix
In-Reply-To: <1211@ttds.UUCP>
References: <1207@ttds.UUCP>
Organization: CWI, Amsterdam

In article <1211@ttds.UUCP> you write:
 > do_nextevent()
 > {
 > 	XAnyEvent e;
 > 
 > 	XNextEvent(display, &e);
 > }

Perusing the X sources reveals that the second parameter of XNextEvent
is not of type *XAnyEvent but of type *XEvent (which is a union of
all kinds of events).  Probably an XEvent is larger than an XAnyEvent,
so XNextEvent will scribble somewhat on the stack, and all kind of
things may happen.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

To: jonasn@ttds.UUCP
Subject: Re: DS3100: buggy cc
Newsgroups: comp.unix.ultrix
In-Reply-To: <1211@ttds.UUCP>
References: <1207@ttds.UUCP>
Organization: CWI, Amsterdam

In article <1211@ttds.UUCP> you write:
 > do_nextevent()
 > {
 > 	XAnyEvent e;
 > 
 > 	XNextEvent(display, &e);
 > }

Perusing the X sources reveals that the second parameter of XNextEvent
is not of type *XAnyEvent but of type *XEvent (which is a union of
all kinds of events).  Probably an XEvent is larger than an XAnyEvent,
so XNextEvent will scribble somewhat on the stack, and all kind of
things may happen.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

dik@cwi.nl (Dik T. Winter) (06/07/89)

In article <8168@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
etc...
Sorry about that, something gone wrong; it was not my intention
(and I cannot cancel).
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax