how to troubleshoot a "bus error" ?

IRIX/Nekoware development, porting and related topics.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
dexter1
Moderator
Moderator
Posts: 2735
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: how to torubleshoot a "bus error" ?

Unread postby dexter1 » Fri Nov 20, 2015 4:36 am

A turn of events: I have found the cause of the Bus Error in 3.4.x
I will walk all of you through this, so you know now what to do when encountering bugs like these:

Code: Select all

mech003 /usr/people/everdij/xcircuit/xcircuit-3.4.3> /usr/nekoware/bin/wish8.4 lib/tcl/xcircuit.tcl
Starting xcircuit under Tcl interpreter
Bus error (core dumped)

...upon clicking of the canvas. Since we have a core we can run dbx:

Code: Select all

mech003 /usr/people/everdij/xcircuit/xcircuit-3.4.3> dbx /usr/nekoware/bin/wish8.4                     
dbx version 7.3.4 (86441_Nov11 MR) Nov 11 2002 11:31:55
Core from signal SIGBUS: Bus error
(dbx) where                   

Thread 0x10000
>  0 makepress(clientdata = 0x1000000) ["/usr/people/everdij/xcircuit/xcircuit-3.4.3/events.c":1140, 0x4203d4]
   1 <Unknown>() [< unknown >, 0x1932db0]
(dbx)

Two things:
1) Since Tcl/TK looks to be multithreading, which makes sense for a graphical toolkit, the trick is to not debug the xcircexec or any other program, but the tcl shell itself, in this case wish8.4
2) xcircuit events.c line 1140 looks to be suspect. In order to verify this i attempted to run the xcircuit tcl program from the debugger:

Code: Select all

(dbx)  run lib/tcl/xcircuit.tcl
PC value from core file (0x0) is not part of the program.
Assuming return register value (0x0) usable to locate PC.
Process 58056 (wish8.4) started
Starting xcircuit under Tcl interpreter

Process 58056 Thread 0x10000 (wish8.4) stopped on signal SIGBUS: Bus error (default) at [keyhandler:1994 +0x4,0x423c94]
1994  if ((pressmode != 0) && (keywstate == pressmode)) {
(dbx)  where

Thread 0x10000
>  0 keyhandler(w = (nil), clientdata = (nil), event = 0x7fff2510) ["/usr/people/everdij/xcircuit/xcircuit-3.4.3/events.c":1994, 0x423c94]
   1 xctcl_standardaction(clientData = 0x100145e0, interp = 0x10011be0, objc = 4, objv = 0x7fff2620) ["/usr/people/everdij/xcircuit/xcircuit-3.4.3/tclxcircuit.c":6721, 0x4a75bc]
   2 <Unknown>() [< unknown >, 0x19174e0]
(dbx)

Another Bus Error, this time at line 1994 in events.c. BTW, i pressed 'l' to load the library when this Bus Error happened.

So what are those lines and routines in events.c?

Code: Select all

1129 #ifdef TCL_WRAPPER
1130 xcTimeOutProc makepress(caddr_t clientdata)
1131 #else
1132 xcTimeOutProc makepress(caddr_t clientdata, xcIntervalId *id)
1133 #endif
1134 {
1135   int keywstate = (int)clientdata;
1136
1137   /* Button/Key was pressed long enough to make a "press", not a "tap" */
1138
1139   areastruct.time_id = 0;
1140   pressmode = keywstate;    <-----
1141   eventdispatch(keywstate | HOLD_MASK, areastruct.save.x, areastruct.save.y);
1142}

Code: Select all

1987      if (areastruct.time_id != 0) {
1988         xcRemoveTimeOut(areastruct.time_id);
1989         areastruct.time_id = 0;
1990         keywstate = getkeysignature(event);
1991      }
1992      else {
1993         keywstate = getkeysignature(event);
1994    if ((pressmode != 0) && (keywstate == pressmode)) {    <-----
1995            /* Events that require hold & drag (namely, MOVE_MODE)   */
1996       /* must be resolved here.  Call finish_op() to ensure   */
1997       /* that we restore xcircuit to   a state of sanity.   */

Both involve a comparison/equation of pressmode and keywstate. keywstate is an int but pressmode is not defined in the function, so it must be globally defined at the top of events.c:

Code: Select all

63 extern int pressmode;

Oh it's declared external, so are there other declarations for pressmode? :

Code: Select all

mech003 /usr/people/everdij/xcircuit/xcircuit-3.4.3> grep pressmode *
events.c:extern int pressmode;
events.c:   pressmode = keywstate;
events.c:        if ((pressmode != 0) && (keywstate == pressmode)) {
events.c:           pressmode = 0;
keybindings.c:extern Boolean pressmode;
keybindings.c:   if (pressmode) {
tclxcircuit.c:extern Boolean pressmode;
tclxcircuit.c:         pressmode = True;
tclxcircuit.c:   pressmode = False;     /* Done using this to track 2-button bindings */
xcircuit.c:Boolean       pressmode;   /* Whether we are in a press & hold state */
xcircuit.c:   pressmode = FALSE; /* not in a button press & hold mode yet */
xcircuit.c:      pressmode = True;      /* 2-button mouse indicator */
xcircuit.c:   pressmode = False;        /* Done using this to mark 2-button mouse mode */

... WhiskeyTangoFoxtrot, They mixed int with Boolean declaration for pressmode? ... No wonder IRIX SIGBUS'ses when it encounters this.
But what should be the correct type? Int or Boolean? A grep of pressmode in xcircuit 3.8.78 shows this:

Code: Select all

mech003 /usr/people/everdij/xcircuit/xcircuit-3.8.78> grep pressmode *     
events.c:extern int pressmode;
events.c:   pressmode = keywstate;
events.c:        if ((pressmode != 0) && (keywstate == pressmode)) {
events.c:           pressmode = 0;
keybindings.c:extern int pressmode;
keybindings.c:   if (pressmode == 1) {
tclxcircuit.c:extern int pressmode;
tclxcircuit.c:         pressmode = 1;
tclxcircuit.c:         pressmode = 1;
tclxcircuit.c:   pressmode = 0; /* Done using this to track 2-button bindings */
xcircuit.c:int   pressmode;   /* Whether we are in a press & hold state */
xcircuit.c:   pressmode = 0;    /* not in a button press & hold mode yet */
xtgui.c:extern int pressmode;   /* Whether we are in a press & hold state */
xtgui.c:         pressmode = 1;         /* 2-button mouse indicator */
xtgui.c:   pressmode = 0;       /* Done using this to mark 2-button mouse mode */

So it must be an int. As a quick test i tried to declare pressmode as Boolean for fun and indeed, no more Bus Errors. The program kinda works but i don't see any lines or libraries. I do see a grid though...

So fixing this makes the Bus Error disappear. I haven't done that for this particular version, because you might want to patch a higher code version of xcircuit where the grid disappears.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
dexter1
Moderator
Moderator
Posts: 2735
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: how to torubleshoot a "bus error" ?

Unread postby dexter1 » Fri Nov 20, 2015 6:44 am

I've attached a patch file for xcircuit 3.4.3. It replaces pressmode declarations from Boolean to int
xcircuit-3.4.3.patch
(2.75 KiB) Downloaded 27 times
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to torubleshoot a "bus error" ?

Unread postby hamei » Fri Nov 20, 2015 7:07 am

dexter1 wrote:I've attached a patch file for xcircuit 3.4.3. It replaces pressmode declarations from Boolean to int

I'd have thanked you sooner but I'm sitting here in awe ... I know, that's how it is supposed to be done but still.

Thanks beaucoupissimo, dexter1.

I'm going to go back and read that post another couple hundred times now :P

(The program is worth some trouble, it's really a nice application)
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to torubleshoot a "bus error" ?

Unread postby hamei » Fri Nov 20, 2015 7:50 pm

A little update ... by applying dexter1's skillful and talented analysis and the changes incorporated in his 3.4.3 patch to xcircuit-3.6.39, we get - violin !

xcircuit-3.6.39.jpg

This is 3.6.39 because at 3.6.40 we encounter the dreaded Phase Change where an even more mysterious error creeps into the source. So hopefully this is just a midway improvement but it's still better than 3.3.38 :D

If someone without a compiler wants this version I can put together a tarfile but with a little luck we (mouse in my pocket, yes) will get to 3.9.40 which does have some useful improvements.

To build yourself :

I have to put the full path to xpm.h into configure. The README indicates xpm is not necessary but at least here, without it some things don't work.

Add dexter1's patch changes to the various C files. Basically this is changing < pressmode > to an integer and replacing "True" with 1 and "False" with 0 in several places.

parameter.c needs a NULL added, this is also in the patch and also in a thread here from ages ago.

tkPixmap.c and xcircuit.c need the full path to xpm.h added - at least for me. My environment is screwed up ?

Then a straight gmake / gmake install.

Then, in /your_base_directory/lib/tkcon.tcl, around line 44 you have to remove the < -exact > switch from the version check. Anything over 8 should work, the -exact thing is kind of a pain in the rear.

Bob's yer uncle :P

(Yes I know, that "circuit" will not work. It's just a bunch of entities dragged onto a drawing with lines added. But all the features seem to work - library, wires, cut, edit, move, rotate, etc. I didn't test everything but so far, all the basics seem to be working)

Besides circuit symbols there are flowchart and music symbols for download from opencircuitdesign and one can easily imagine network symbols - routers, switches, servers etc. So this thing should be useful for people in a variety of areas. And it should be fast enough even on an Indigo (1) ...

edit : just tried 3.6.40, where the other error started, except with the Boolean - integer error fixed.

It works.

So the next error is somewhere up the road from here.

edit ii : 6.3.41 is the first instance of the Next Big Error. 40 is okay. Sorry about that, bad notes :(
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
vishnu
Donor
Donor
Posts: 3174
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: how to troubleshoot a "bus error" ?

Unread postby vishnu » Sat Nov 21, 2015 1:54 am

Wow, that is very nice! :D

Except, since I have Orcad 16 at work I'll probably never use it... :cry:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
dexter1
Moderator
Moderator
Posts: 2735
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: how to troubleshoot a "bus error" ?

Unread postby dexter1 » Sat Nov 21, 2015 7:20 am

Few comment again, since i don't have opportunity to send a xcircuit window on the o200 from work to home:

- I realized the .Xdefaults file is actually for the Xw version of xcircuit, but nobody uses that since the xcircuit developer mentioned code problems with Xw, i.e. it is shite.
- With Phase Change you mean the library display/non-display? I've reread the entire post and i think you mean the ibrary display bug being the cause of 3.6.41 not working correctly.

If you now have two versions side-by-side, one without the bug and the other with the bug, do a version diff. That way you can easily check differences. Most likely code changes in canvas refresh or mouse event handling might be the culprit.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Sun Nov 22, 2015 3:28 am

dexter1 wrote:If you now have two versions side-by-side, one without the bug and the other with the bug, do a version diff. That way you can easily check differences. Most likely code changes in canvas refresh or mouse event handling might be the culprit.

Thanks, Mr Dex. I believe I have the problem semi-isolated now, it's in events.c, but took a few hours off to make it fit the Family ...
colorscheme.jpg

Wasn't exactly straightforward, settings are spread over a couple places but not too bad. I'll share after I hunt down the last few recalcitrants.

Maybe someone artistic could do something about those icons ? Drawing is not my strong suit :(

Then we'll get back to the Important Stuff. Can't let vish steal all the glory :P
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Sun Nov 22, 2015 4:41 am

Okey-dokey, Smokey ... 3.6.40 works, 3.6.41 does not. But importing events.c from 40 into 41, with the addition of one line, does work. Differences are very few :
tkdiff.jpg

As marked ... (this is maybe not the best way ever, but ...)
differences.jpg

The last area is the one that seems the most suspicious ...

The release notes aren't too much help on this problem but here they are :

XCircuit wrote:posted: July 18, 2006 at 2:40am version: 3.6 revision: 41
2006-07-17 21:06 tim A number of changes: Modified the way XCircuit creates backup files, avoiding spurious timeout errors that occur in Linux. Does not write the backup file multiple times if there is no activity. Added a command "config suspend" that allows scripts to suspend drawing to the screen during read-in of scripted files. This function does not yet cover all cases where drawing occurs, but it catches the major ones. Corrected numerous Tcl command-line commands. Additional options will be written up in the documentation. "object make" now returns a handle to the newly-generated instance ("symbol.tcl" has been modified to no longer attempt to work around the error), and "object make ... -force" will generate a new empty object (previously disallowed), avoiding the necessity of creating some dummy element and then erasing it.


and the newer, might be relevant ? Same subject, the new "suspend" thingy ...

posted: July 19, 2006 at 2:40am version: 3.6 revision: 42
2006-07-18 17:08 tim Added new TCL script "edif.tcl" that handles EDIF 2.0.0 file format reads. Includes some source file bug fixes, such as having the command "parameter make ..." return a TCL_ERROR if an attempt is made to create a duplicate parameter name. Also, more drawing routines removed when in "suspend" mode, which otherwise cause XCircuit to produce a weird Tcl result on an ordinary command (in this case, a "no such variable XCOps(focus)" error was returned from the command "label type"). The flag TCL_NAMESPACE_ONLY was removed from calls to Tcl_Var, which should prevent the above error from occurring even outside of "suspend" mode.
Also: Rewrote the "config suspend" mechanism slightly so that a single call to "config suspend" puts XCircuit in a "temporarily suspended" drawing mode. Any key or button press in the window will return XCircuit to a normal drawing state. This prevents XCircuit from getting hung in suspend mode if, for example, the "read_edif" procedure halts in the middle with an error return value. "config suspend" can be called twice in a row to prevent keystrokes from breaking the suspend state, in case anyone cares.
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Mon Nov 23, 2015 3:14 am

Here's a question from logic, not programming, but still ...

Code: Select all

/*--------------------------------------------------------------*/
/* Set the name for a new user-defined object and make the   */
/* object.  If "forceempty" is true, we allow creation of a new   */
/* object with no elements (normally would be used only from a   */
/* script, where an object is being constructed automatically).   */
/*--------------------------------------------------------------*/

objinstptr domakeobject(int libnum, char *name, Boolean forceempty)
{
   objectptr *newobj;
   objinstptr *newinst;
   genericptr *ssgen;
   oparamptr ops, newop;
   eparamptr epp, newepp;
   stringpart *sptr;
   XPoint origin;
   short loclibnum = libnum;

   if (libnum == -1) loclibnum = USERLIB - LIBRARY;

   /* make room for new entry in library list */

   xobjs.userlibs[loclibnum].library = (objectptr *)
   realloc(xobjs.userlibs[loclibnum].library,
   (xobjs.userlibs[loclibnum].number + 1) * sizeof(objectptr));

   newobj = xobjs.userlibs[loclibnum].library + xobjs.userlibs[loclibnum].number;

   *newobj = delete_element(areawin->topinstance, areawin->selectlist,
         areawin->selects, NORMAL);

   if (*newobj == NULL) {
      objectptr initobj;

      if (!forceempty) return NULL;

      /* Create a new (empty) object */

      initobj = (objectptr) malloc(sizeof(object));
      initmem(initobj);
      *newobj = initobj;
   }

   invalidate_netlist(topobject);
   xobjs.userlibs[loclibnum].number++;


In the first line after the comment, "forcempty" is declared as a Boolean.

But about seven lines from the bottom, it's states "if forcempty returns NULL .."

How can a Boolean return null ? It's either true or false. How can it ever be null ? That's not an option ... when did you stop beating your wife ?

Pretty sure the problem is in this "suspend" thingy. There's only about twenty lines changed in events.c, all involving the new "suspend" function, and events.c is THE file that causes the weird behaviour.
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
Trippynet
Donor
Donor
Posts: 783
Joined: Thu Aug 15, 2013 6:22 am
Location: Aberdeen, Scotland, UK

Re: how to troubleshoot a "bus error" ?

Unread postby Trippynet » Mon Nov 23, 2015 3:45 am

It's not the Boolean which is set to NULL, it's the return value of the function. The function is of type "objinstptr". So if forcempty is false (at this stage in the code), the function returns a objinstptr with a NULL value. Without knowing what type of object "objinstptr" is, and how it's used elsewhere, it's difficult to say what type of impact this may have.
Systems in use:
:Indigo2IMP: - Nitrogen: R10000 195MHz CPU, 384MB RAM, SolidIMPACT Graphics, 36GB 15k HDD & 300GB 10k HDD, 100Mb/s NIC, New/quiet fans, IRIX 6.5.22
:Fuel: - Lithium: R14000 600MHz CPU, 4GB RAM, V10 Graphics, 72GB 15k HDD & 300GB 10k HDD, 1Gb/s NIC, New/quiet fans, IRIX 6.5.30
Other system in storage: :O2: R5000 200MHz, 224MB RAM, 72GB 15k HDD, PSU fan mod, IRIX 6.5.30

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Mon Nov 23, 2015 4:03 am

Trippynet wrote:It's not the Boolean which is set to NULL, it's the return value of the function.

I will be the first to admit that the "logic" of programming languages often escapes me :P

But still pretty sure it is in events.c This is the only other change of any significance in that file ....

Code: Select all

  /* copy name into object and check for conflicts */

   strcpy((*newobj)->name, name);
   checkname(*newobj);

   /* generate library instance for this object (bounding box   */
   /* should be default, so don't do calcbbox() on it)      */

   addtoinstlist(loclibnum, *newobj, FALSE);

   /* recompile the user catalog and reset view bounds */

   composelib(loclibnum + LIBRARY);
   centerview(xobjs.libtop[loclibnum + LIBRARY]);

   return *newinst;
}

Which suspiciously generates the library and resets the view bounds ... altho the crash happens exactly when you drop the object but if there's nothing to drop it onto ... ?
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
dexter1
Moderator
Moderator
Posts: 2735
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: how to troubleshoot a "bus error" ?

Unread postby dexter1 » Tue Nov 24, 2015 8:19 am

Found it (I think) but i need people to test this, since it's late and i have to bike home in the rain.

I've looked at all the data in Hamei's post and the introduction of "suspend" in 3.6.41 struck a nerve a few days ago, because i remembered i got several warnings during compile of the more recent 3.8.78.

I also couldn't build 3.6.4x since it cannot find the function/command "unsetenv" at runtime. Strange, since it did work last week. I have more issues with the 3.6 branch since it wants to include /usr/lib and pollute my linker with o32 libraries :(

Anyway because of the grumpy behavior of my o200 today, i list some "suspend" compiler warnings here:

Code: Select all

cc-1183 c99: WARNING File = events.c, Line = 516
  An unsigned integer is being compared to zero.

     if (xobjs.suspend >= 0) return;

And many many more. This was from 3.6.41, but 3.8.78 is also littered with those. Interesting to see that exactly the introduction of the suspend field in 3.6.41 in the xobjs struct causes the "phase change".

So what type is xobjs.suspend ? Answer is in xcircuit.h somewhere at the end:

Code: Select all

   u_short      new_changes;
   char         suspend;        /* suspend graphics updates if TRUE */
   short        numlibs;
   short        pages;

A char. Erm is it signed or unsigned? After some googling i found in http://unix.derkeiler.com/Newsgroups/co ... /0424.html

Dr. David Kirkby wrote:
> Erik Max Francis wrote:
>
>>"Dr. David Kirkby" wrote:
>>
>>
>>>char foo;
>>>
>>>is asking for trouble, if you hope to put negative numbers in foo.
>>
>>Indeed. The Standard leaves it unspecified whether an unadorned char is
>>signed or unsigned.
>
>
> I've just confirmed that AIX and IRIX declare it unsigned, whereas
> Solaris, Linux, AIX, HP-UX, Tru64, NetBSD, OpenBSD all declare it
> signed. Although I've not had chance to fix the problem yet, I think
> that explains why my program for computing the properties of
> transmission lines
> http://atlc.sourceforge.net/
> works on Solaris, Linux, AIX, HP-UX, Tru64, NetBSD, OpenBSD, but not
> on AIX or IRIX.
>
> At least fixing it should not be too hard - just needs a bit of time.

I don't have an SGI system handy to check the proper flag but both the
MIPSPro C and GNU-C compilers on Irix have a flag to cause all chars not
explicitly declared as unsigned to be signed. I ran into the same
problem when I ported a package from Intel/Linux to Irix.


Wow, a compiler option to make char behave as being signed? Let's see what "man c99" has to say:

Code: Select all

     -signed     Causes values of type char to be treated as if they had
                 type signed char (which can affect the result of integer
                 promotions), but the values of CHAR_MIN and CHAR_MAX are
                 not affected.  The default is to treat values of type char
                 as if they had type unsigned char.

Thus, does CFLAGS need '-signed' as extra option? Is it that simple?
So if i set that and recompile xcircuit 3.8.78, will i see the library again?

xc3878.png


Affirmative. I also see the grid :)
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Tue Nov 24, 2015 5:16 pm

dexter1 wrote:Found it (I think) but i need people to test this, since it's late and i have to bike home in the rain.

Jeeze, dexter. I'm speechless. Thank you.

I'll try this out in a few minutes.

Also, I had this thought but didn't want to be a distraction, but those compiler warnings should be good clues. I also noticed dozens of the things flashing past and wondered how to capture them ? I've never used < tail > but that should work ? Or is there an easier way ?
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
nekonoko
Site Admin
Site Admin
Posts: 8145
Joined: Thu Jan 23, 2003 1:31 am
Location: Pleasanton, California
Contact:

Re: how to troubleshoot a "bus error" ?

Unread postby nekonoko » Tue Nov 24, 2015 5:38 pm

hamei wrote: Or is there an easier way ?


I'd just redirect the compiler output to a text file, then you can search through it later for whatever you need, eg.

Code: Select all

cc -v > output.txt >2&1
directs all output of 'cc -v' (including stderr) to 'output.txt'.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: how to troubleshoot a "bus error" ?

Unread postby hamei » Tue Nov 24, 2015 7:01 pm

nekonoko wrote:I'd just redirect the compiler output to a text file,

Too easy :P I'll try that next time, thanks ...

Confirmation 1:
xcircuit_3-8-78.jpg

Confirmation 2:
xcircuit_3-9-40.jpg


Altho I am not overjoyed with the 3.9.40 .... first, it absolutely refuses to find xpm no matter what I do. Second, I had to go into the Makefile and ditch

Code: Select all

cairo.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra
elements.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra
events.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra
fontfile.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra
text.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra
utf8encodings.$(OBJEXT) : CFLAGS += -pedantic -Wall -Wextra

which makes me wonder what other gcc-isms may have been missed.

But 3-8-78 seems to be fine, it's the 'stable' build anyway, so maybe for the moment ... don't know. It's easy enough to keep both installed, just change the startup script, one is installed in /basedir/lib/xcircuit-3.8.78 and the other in /basedir/lib/xcircuit-3.9.40

One step for man, one giant leap for Mankind :D
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered


Return to “SGI: Development”

Who is online

Users browsing this forum: No registered users and 2 guests