Path: utzoo!attcan!uunet!richsun!ken
From: ken@richsun.UUCP (Ken Marks)
Newsgroups: comp.windows.x
Subject: Re: XGDB core dumps after GCC 1.32 compilation
Message-ID: <166@richsun.UUCP>
Date: 18 Jan 89 15:02:50 GMT
Reply-To: ken@richsun.UUCP (Ken Marks)
Organization: RICH Inc., Franklin Park, IL
Lines: 88

I found out what was causing the "X Toolkit Warning: No type converter 
registered for 'String' to 'EditMode' conversion" message and what was causing 
the core dump (the two are unrelated).  First, the core dump occurs when the
pointer "fi" is dereferenced in about line 109 of xgdb.c.  As far as I could
tell xgdb_display_source() gets called before everything is set up.  There is
an earlier return that checks that containing_widget is non-NULL.  In this
spirit, I added a test for "fi" being NULL and likewise returned.  

The problem of the type converter comes from the type converter being used
before it was registered (seems obvious).  The function create_text_widget
needs to create a text widget (which registers the type converter) before 
using the type converter to get up its args.  The second chunk of diff fixes
this.  How this ever worked before is a mystery to me, but then again a lot
of things are mysteries to me...

I hope this helps get people going with xgdb.  I personally do not use it
since I feel that it is still a little rough around the edges in terms of user
interface (i.e. It's still not up to the level of a dbxtool).  The points where
it could use some tweaking are 1) place output in a window within xgdb (an 
ansitool widget would be nice) 2) give some visual feedback in the source code
window as to where breakpoints are set and where the program has stopped 
execution (a la dbxtool) 3) add an "expand selection" mechanism 4) add an
option to NOT scroll the source code so that the current line is in the center
of the window (with large windows this gets annoying).

I know the rules: don't compain about problems - fix them and submit the 
patches.  Well, as soon as I get a little breathing room in my schedule, I
plan on it.  Anybody else who is interested in patching this program into a
truely usable piece of code, I would be interested in hearing from you.
(Anybody from SUN consider working on this???...)

			-Ken Marks

>>> Sorry for the ^L's in the diffs, but they are in the code... <<<

*** xgdb.c.orig	Tue Jan 10 14:25:55 1989
--- xgdb.c	Tue Jan 10 15:20:33 1989
***************
*** 105,111 ****
  
    /* Get the symtab and line number of the selected frame.  */
  
!   fi = get_frame_info (selected_frame);
    sal = find_pc_line (fi->pc, fi->next_frame);
  
    /* Strictly this is wrong, but better than a blank display */
--- 105,113 ----
  
    /* Get the symtab and line number of the selected frame.  */
  
!   if ((fi = get_frame_info (selected_frame)) == NULL)
!     return;
! 
    sal = find_pc_line (fi->pc, fi->next_frame);
  
    /* Strictly this is wrong, but better than a blank display */
***************
*** 421,427 ****
--- 423,433 ----
    static Arg fileArgs[3];
    XtTextSource src;
    XtTextSink   sink;
+   Widget text_widget;
  
+   text_widget = XtCreateManagedWidget("disk", textWidgetClass, parent, 
+     NULL, 0);
+ 
    XtSetArg (fileArgs[0], XtNfile, filename);
    src = XtDiskSourceCreate(parent, fileArgs, 1);
    sink = XtAsciiSinkCreate(parent, NULL, 0);
***************
*** 429,435 ****
    XtSetArg (fileArgs[0], XtNtextOptions, scrollVertical);
    XtSetArg (fileArgs[1], XtNtextSource, src);
    XtSetArg (fileArgs[2], XtNtextSink, sink);
!   return XtCreateManagedWidget("disk", textWidgetClass, parent, fileArgs, XtNumber (fileArgs));
  }
  
  /* Entry point to create the widgets representing our display.  */
--- 435,442 ----
    XtSetArg (fileArgs[0], XtNtextOptions, scrollVertical);
    XtSetArg (fileArgs[1], XtNtextSource, src);
    XtSetArg (fileArgs[2], XtNtextSink, sink);
!   XtSetValues(text_widget, fileArgs, XtNumber (fileArgs));
!   return text_widget;
  }
  
  /* Entry point to create the widgets representing our display.  */