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