SGI: Development

Full story ;

Xcircuit is a pretty nifty program -- besides making circuit diagrams you can use it for flowcharts, network layouts, all kinds of graphy kind of things. And it's tickletock, builds easily on Irix, up to version 3.3.38 everything is wonderbra. Output is PostScript, easy to pdf it, scalable, cool.

But you know version lust. And besides, there's a couple new export options in the newer revs that I could use. So.

Yeah, well. The newest (3.9.x) wants cairo, so that's out.

Built the biggest prior incarnation, 3.8.78. Built fine. Seemed to work fine, at first. But it wasn't quite right for drawing, then when I tried to grab an entity from the lbrary, there was no library. Well, there was, but it was invisible. You can drag the entity onto your drawing, where it shows (as well as where it used to be when you initially grabbed it) but if you mimimize the window or a dropdown menu covers the drawing area, the drawing disappears. You can print it but can't see it. This is WYCSIWYG printing, I guess

Backed my way down to 3.6.40 and found that this is where the bus error disaster crept in. Okay, I can use 3.6.39 for a while, at least that's quite a bit debugged from 3.3.38, right ?

Umm, well, no ... everything works very well except for when you click to drop a library item onto the drawing page. Then POOF !! Bus error and the program disappears.

Backtracked down the rev levels, that behavior appeared at 3.4.0. So the version in nekoware (3.3.38) is the newiest that works in Irix.

Unless I (i.e., someone smarter than me gives directions, I do the grunt work) can diagnose that bus error ...

It's a pretty useful program, actually. Even 3.3.38 is handy. One little fix would move us up three major versions, hint hint.

I tried firing Xcircuit up , it requires tcl version > 8. I have tcl-8.4.11 installed ?

uunix wrote: I tried firing Xcircuit up , it requires tcl version > 8. I have tcl-8.4.11 installed ?

Wherever your base installation is - nekoware ? - above that there will be a /bin and /lib directory, then above the lib an /xcircuit-3.x directory. I'm guessing here but in nekoware, maybe /usr/nekoware/lib/xcircuit-3.3/ ... Inside that there will be a tkcon.tcl script. Edit that basterd to get rid of the -equal requirement. On mine it's at about line 44. It's insisting on one particular version. Mine works fine at 8.6.4, ymmv.

I edited some crap out of the startup script, too. No need to look for Cygwin on an Octane ... maybe Voidfoo already did that for nekoware.

If you are going to build it from scratch, yell and I can save you a few moments

If you find it too gaudy, there is a resource.tcl file that will Irixxify it pretty well. The Xdefaults don't seem to do anything ?

It's a little strange at first but after you figure out the different way it works, pretty fast. The way it gets shapes from the library onto the drawing is weird to figure out, but after a few minutes pretty neat. Read the tutorial. If you like keyboard shortcuts this is the program for you !

Many bus errors are results of MipsPro aggressive optimization, so first try to build a version without optimization and look, if you still have the errors. If yes build a version with debug info (-g) and go into it with dbx to find the function where to error occurs. If you are not able to find it that way the error may possibly be in a shared library. In this case you can start to debug all dependent shared libraries in the same way. If you find the function you have to go into the code and try to understand what happens there.

diegel wrote: Many bus errors are results of MipsPro aggressive optimization, so first try to build a version without optimization and look if you still have the errors.

Ha ! Thank you, tried that, no joy in mudville but I did isolate the crash to a particular activity (pushing any mouse button at one point in the process.)

So now it's hunt through code I don't understand for an error I don't understand, but still, forward movement

Hamei, is there a simple check for the library inport and the display bug?
Xcircuit 3.8.78 compiles fine on my O200, but i'm not sure what the exact problem is. It would be a real shame if you have to go back in versions to make it run, getting old bugs re-introduced that way, whereas it might be a very simple fix to get library import and displaying running.
It could be something as trivial as the visual colorspace in use...

dexter1 wrote: Hamei, is there a simple check for the library inport and the display bug?
Xcircuit 3.8.78 compiles fine on my O200, but i'm not sure what the exact problem is.

I managed to build 3.9.40 as well, by --without-cairo-ing it ... same problem tho (at least for me)

Xcircuit does a kind of odd thing to place items on the drawing area. Start the program. Shows up fine, looks good.

Now, the way you place an entity in your drawing is, with the cursor in the drawing area, either hit "l" (that's a small L) or go to Window -> Library Directory or Window -> Go to Library (then choose one).

It should instantly show the library (or all the libraries) in the drawing area.

At this point you can lmb an entity and the display will poof turn into the drawing area. If you do it from the full library page like shown above, it first goes to that individual library page then you can drag from there.

The mouse is a little tricky. A fast click is a click. A long click or click and hold is a drag. A short click will start drawing a line, so if it does that, don't freak out. Right mouse button is cancel, two rmb's is cancel cancel until the line you didn't want goes away. Middle mouse is the "finished" button.

Now with lmb you should be able to drag the entity all over the screen.


This works for me up to 3.3.38. At 3.4.0 I start to get bus error *just* when I drop the entity onto the drawing area. (Seems like the problem might be with that mouse action ? Or maybe what that mouse action does. Or maybe the phase of the moon But it's connected for sure). That continues up to 3.6.40, where Behavior Two kicks in - you can't see the items in the libraries. They are there, but invisible. And anything that has to do with refreshing the page doesn't behave properly, either.

With the earlier ones (bus error) that happens *exactly* when you do a mouse click to drop the entity onto the screen.

With the latest version, 3.9.40 (built that today, at least it gives some sort of error message in the terminal) does this :



So I am pretty sure it's fixable, I just don't know how

Actually, two fixes might be nice, since the earlier ones are a bit snappier. Might be nicer on an Indigo or something ...

Oh, one other point. Configure doesn't like to find xpm.h I originally thought "who cares, it's just for the icon" but in fact, without xpm the early versions are screwed up. Supposedly at 3.6.40 that changed (suspicious coincidence right there) but it may still really need Xpm. I got around it by cramming the full path into the configure script and some of the files, since --with-xpm=/usr/Motif-2.1/include/X11 (or whatever, doing that from memory) did not work. That trick did not even work in the 3.9.40 version, so the one I just built is once again without xpm. Not supposed to matter but I am suspicious of that, at least on Irix.

Tried diegel's suggestion of backing off on optimization but no success

As you can see, it has the potential to be a pretty nifty program. It can be easily Irixxified, too. Xdefaults don't seem to do anything but there is a resource.tcl file that does fix most of the tickletockiness of the windows. Maybe the Xdefaults work in the Python version. It's also pretty fast and accurate (the snapping is quite nice.) And it puts out in PostScript, so it's real easy to convert to just about anything.

Hamei, is hat the Xw version of xcircuit you are using? You're typing ./xcircuit which leads me to believe you are using the (old) X interface.

Try going to tcl/tk. Nekoware has the 8.4.11 versions which are fine and do not require any dependencies.

When building xcircuit 3.8.78, or 3.9.x for that matter, use: ./configure --with-tcl=/usr/nekoware/lib --with-tk=/usr/nekoware/lib
And when finished, do:

And let us know what you get. I actually reproduced the library display bug on my remote X terminal (Ubuntu 15.10 Latitude laptop) with the xcircuit program running on the o200.

PS: i was able to compile 3.8.78 with tcl/tk it on my Ubuntu Laptop and the first thing i notice that there is a "grid" which is missing in the irix-xcircuit window. Sure enough, when i press 'l' i see the library...

dexter1 wrote: Hamei, is hat the Xw version of xcircuit you are using? You're typing ./xcircuit which leads me to believe you are using the (old) X interface.

No, it's tickletock. That's the script that it makes when you do gmake install. It lives in /whereveryouputtit/bin and calls /whereveryouputtit/lib/xcircuit-version/the_executable_script. Gmake install creates all that stuff and rearranges the files, so that the environment settings are no longer necessary.

Try going to tcl/tk. Nekoware has the 8.4.11 versions which are fine and do not require any dependencies.

I'm running 8.6.4 here ...

When building xcircuit 3.8.78, or 3.9.x for that matter, use: ./configure --with-tcl=/usr/nekoware/lib --with-tk=/usr/nekoware/lib
And when finished, do:

Code: Select all

setenv XCIRCUIT_LIB_DIR ./lib
setenv XCIRCUIT_SRC_DIR ./lib/tcl
./lib/tcl/xcircuit.sh

That's just for running it to test prior to installing. After gmake install, there will be a startup script in your /base_directory/bin

The one I wasn't able to conquer was making configure find xpm. It should work with --with-xpm=/usr/Motif-2.1/include/X11 (or words to that effect) but refuses. I got around that by pounding the entire path into configure and tkPixmap.c and xcircuit.x

Then that trick fails with 3.9.x

For several versions you have to edit the /base_directory/xcircuit_version/lib/tkcon.tcl script to get rid of the -exact switch on line 44 or 45. Unless you have exactly tickletock 8.6.0, anyhow

I actually reproduced the library display bug on my remote X terminal (Ubuntu 15.10 Latitude laptop) with the xcircuit program running on the o200.

Ah-ha ! Two cases of the same problem. We almost got us a convoy !

PS: i was able to compile 3.8.78 with tcl/tk it on my Ubuntu Laptop and the first thing i notice that there is a "grid" which is missing in the irix-xcircuit window. Sure enough, when i press 'l' i see the library...

That's how it is supposed to work. It does work that way on Irix at 3.3.38. Then at 3.4 it goes totally to heck. Somewhere later it comes back but does a bus error when you hit "l" or Window -> Library. It does this up until 3.6.40 when the behavior changes, no longer a bus error but now the library is invisible. And stays that way until The End (3.9.40, I think. That will build for you also, just add --without-cairo to your configure. If you find a solution for the xpm problem, please pass it along ?).

diegel wrote: Many bus errors are results of MipsPro aggressive optimization

A bus error in code which "works" on x86 is usually caused by unaligned memory access . Compiler optimization may expose it but the root of the problem is a flawed assumption by the coder. x86 CPUs will usually fix up unaligned access (at the cost of performance), but RISC CPUs will abort with a SIGBUS.

A stack trace or a SIGBUS handler should tell you where the offending access is happening. But since the cause of the problem is in the poor design of the code, the fix is usually not a oneliner.

Thanks Hamei for the additional info.

I've done some more tests, mainly on 3.8.78:
- Linux xcircuit build 3.9.40 with tck/tk and without cairo give the same X_CopyArea crash when placing a library element on the window.
- IRIX gcc-build with xcircuit 3.8.78 -> no grid dots and no library visible
- IRIX MIPSPro build with 3.8.78 and --disable-double-buffer -> no grid dots and no library visible
- IRIX MIPSPro build with cairo from nekoware doesn't compile, probably too old cairo and incompatible pointers. I can cast stuff, but rather not.

Oh and on all IRIX build:



No problems with that fortunately.

As for the bus error. I haven't learned to debug tcl/tk apps in the debugger. If anyone can show this for me, especially for xcircuit, i'd be all ears

dexter1 wrote: As for the bus error. I haven't learned to debug tcl/tk apps in the debugger. If anyone can show this for me, especially for xcircuit, i'd be all ears

This is the Late Model Problem, not the bus error, and you're demanding work way above my rating, but I built 3.9.40 with -g and tried running it from cvd. Didn't give me any information but that's probaly because I am stupid. There is an actual executable in there called "circexec" whioch you can run directly. It still uses tickletock in some way but might be more informative ?

I'd love to kill the bus error cuz that seems like a great first step but here's what I have on the later problem :

le developpeur wrote: Since the error is raised by the X11 server,
it will be necessary to catch it in the source where the XCopyArea
statement is called, and figure out why the target pixmap/window is
null or pointing to some random area of memory, and why.

In xcircuit-3.9, the places it might occur are elements.c lines
2360, 2364, 2380, and 2426.

Usually, these problems that are different from machine to machine are
caused by the interaction between the window manager, Tcl/Tk, and X11.
It will help to know which window or pixmap is undefined, and figure
out why it isn't getting set to a valid memory address.

Hope that helps someone with a brain.

Oh and on all IRIX build:

Code: Select all

checking X11/xpm.h usability... yes
checking X11/xpm.h presence... yes
checking for X11/xpm.h... yes
checking for XpmCreateImageFromData in -lXpm... yes

No problems with that fortunately.

Sigh. But at least in the earlier versions I managed to jam xpm down configure's throat and make it work ...

dexter1 wrote: As for the bus error. I haven't learned to debug tcl/tk apps in the debugger.

Ooookay, hope you can make more sense of this than me.

Built 3.9.40 with the -g switch.

Opened cvd (Workshop Debugger.) Opened the Execution View as well, that shows a little more of what's going on ?

Started xcircuit from the Command window in the debugger. Wa, it actually opened ! Wait, I should open this from the directory with the source code ? Seems to me you should ?

Anyway, it opened, I didn't even get as far as trying to open a Library window, just clicked on one of the menubar commands and kerplowie.


and the Execution view

plus I've got a nice non-responsive xcircuit window left with no text showing.

Maybe should go try to run the one that works, just for a comparison ..

I deleted my recent post again. I accidentally used instead of for testing tcl/tk scripts.
xcircuit 3.8.78 picks up the right wish: so that looks to be okay.

dexter1 wrote: I deleted my recent post again. I accidentally used

Code: Select all

/usr/bin/wish

instead of

Code: Select all

/usr/nekoware/bin/wish8.4

for testing tcl/tk scripts.
xcircuit 3.8.78 picks up the right wish:

Code: Select all

Makefile:WISH_EXE = /usr/nekoware/bin/wish8.4

so that looks to be okay.

I hate having ten versions of things lying around, for just the reason you mention. I have one and only one tickletock, which removes Yet Another Place to Make Errors ....

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:


...upon clicking of the canvas. Since we have a core we can run 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:


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?



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:


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


... 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:


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.

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

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

(The program is worth some trouble, it's really a nice application)

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 !


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

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

(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

Wow, that is very nice!

Except, since I have Orcad 16 at work I'll probably never use it...