Bugzilla Bug 8957

app-sci/xcircuit SIGSEGVs during startup. i've confirmed this on both x86 and
PPC. i'm attaching a patch that will fix this problem. the faulty code is

foo** bar;
*bar = malloc();

my solution is:
foo** bar;
foo* baz;
bar = &baz;
*bar = malloc();

Created an attachment (id=4558) [details]
patch for SIGSEGV

what a crazy hack :) 

not so crazy... i'm pretty sure it's what the author intended. 
let's talk in char's.

he made a char** called newinst. that's a pointer to a pointer to a char.
then he says *newinst = malloc(...). that says i'd like the thing that newinst
points to (a char*) to be assigned whatever malloc returns. but there's a
problem here. his declaration:
char** newinst;
doesn't initialize it's variable. let's say the compiler is nice and initializes
it to NULL. if that's the case,
*newinst = malloc(...);
is really saying
*(NULL) = malloc(...);
which is an obvious SIGSEGV.

all my patch does is create a char* and initialize newinst to the address of
that char*. this allows code like: *newinst = malloc(...) to work just fine.

Hi Jonathan

Thanks for tracking the problem and the patch!
I tried the patch, however the compilation halts with a somewhat misterious
message (the modified code looks syntactically correct to me, but gcc apparently
thinks otherwise). Here is the tailing part:

gcc -DPACKAGE=\"xcircuit\" -DVERSION=\"2.5\" -DPROTOTYPES=1 -DHAVE_LIBM=1
-DHAVE_LIBXT=1 -DSTDC_HEADERS=1 -DHAVE_SETENV=1 -DHAVE_PUTENV=1
-DHAVE_DIRENT_H=1 -DHAVE_U_CHAR=1 -DSCHEMA=1 -DSCHEM_FLAG=\"-schema\" -DLGF=1
-DINPUT_FOCUS=1 -DGS_EXEC=\"gs\" -DHAVE_PYTHON=1 -DHAVE_X11_XPM_H=1 -DHAVE_XPM=1
 -I. -I.  -IXw -DPROG_VERSION=2.5  -DTEMP_DIR=\"/tmp\"     
-DRESOURCES_DIR=\"/usr/share/xcircuit-2.5/app-defaults\"       
-DBUILTINS_DIR=\"/usr/share/xcircuit-2.5\"     -DBUILTINS_FILE=\"\"   
-DUSER_RC_FILE=\".xcircuitrc\"  -DPROLOGUE_DIR=\"/usr/share/xcircuit-2.5\"    
-DPROLOGUE_FILE=\"xcircps2.pro\"        -DSTARTUP_FILE=\"xcstartup.py\"        
-DLGF_LIB=\"lgf.lps\"  -I/usr/X11R6/include -DDOUBLEBUFFER
-I/usr/include/python2.2  -march=i686 -O2 -pipe -fforce-addr
-fomit-frame-pointer -funroll-loops -frerun-loop-opt -malign-functions=4 
-fexpensive-optimizations -ffast-math -c files.c
files.c: In function `objectread':
files.c:1977: parse error before `*'
files.c:2029: `newpath' undeclared (first use in this function)
files.c:2029: (Each undeclared identifier is reported only once
files.c:2029: for each function it appears in.)
files.c:2036: `startpoint' undeclared (first use in this function)
make[1]: *** [files.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/xcircuit-2.5.4/work/xcircuit-2.5.4'
make: *** [all-recursive] Error 1

The same happens without any optimizations. Could you please take a look?
I attach below the modofied ebuild and the patch (combining this bug and #8960)
Thanks!

George

Created an attachment (id=4686) [details]
modified ebuild

Created an attachment (id=4687) [details]
combined patch

george, 
which version of gcc are you using? i just used your combined patch with your
modified ebuild and compilation completed without a hitch. i'm using gcc 3.2.

Hi Jonathan

That was a quick way to find the problem, nice :).
I made this patch conditional on gcc version and the other one unconditional
(for the record: this patch is necessary on gcc-3.2 but breaks on 2.95.x). 
Please test the ebuild. I committed and masked it (I did not bump the revision
not to force the recompilation on platforms where it works now). 
To unmask, please remove '~' (tilda) in KEYWORDS inside the ebuild.
Please report the result, so I could unmask it.
Thanks for your work!

George

tested on PPC and x86 (both gcc 3.2 boxes)-- it works great on both
architectures.

george,
i looked at the xcircuit-2.5.4 available from sourceforge.net and it's different
than the one on the gentoo mirror. specifically this section of code is
different. do you know what this is about?

i'm looking at xcircuit-2.5.4 as available from:
http://sourceforge.net/project/showfiles.php?group_id=4952

Hi Jonathan.

Well, to tell the truth I have little idea why this is a different code than the
one on sourceforge. I wasn't the one who created/added this ebuild, so I
wouldn't really know its original whereabouts. According to Changelog Tod Neidt
might be able to tell little bit more about this. I added him to this bug.

Tod: could you please comment if you have any info on the question?


George

Hi!

Perusing the manifest, it seems the developer of xcircuit makes multiple
releases with incremental changes using the same version number.  It also
appears that the offical homepage has changed to   http://xcircuit.ece.jhu.edu 
which should be updated in the ebuild.  the latest and greatest sources are
found at http://xcircuit.ece.jhu.edu/archive/     Incidentally, the latest
release is 3.0

You will notice that the 2.5.4 tarball is dated 14 May 2002 at the above archive
while the 2.5.4 version on sourceforge is dated  28 April 2002.  Incidentally, I
committed the original ebuild on 5 April 2002 with the src uri pointing to the
old homepage  (It worked fine then, honest :),  so there appears to be at least
three different flavors of 2.5.4 floating around.

I would update the HOMEPAGE and SRC_URI to http://xcircuit.ece.jhu.edu/ and
http://xcircuit.ece.jhu.edu/archive/ respectively as those seem to be the most
current and maintained. Would you mind updating that George, my box is not
developer enable at the moment. It doesn't appear that the sourceforge page is
kept current.

Sorry, for any confusion, I have be out of the saddle for a while and haven't
been able to track changes.

tod

P.S. might consider floating the patches upstream.

Hi Tod

Thanks for clarification! 
I updated HOMEPAGE and SRC_URI in the present ebuild (the source seems to be the
same at least according to diff and md5 sums).
Most likely I'll take care of newer versions, as I am overseing app-sci as well
as couple of dev categories. Though this will have to wait since we are now in a
feature freeze. 
As for this issue: it seems to be resolved now, so I'll just wait for test
reports from ppc/gcc-2.95.3 people and close this bug, unless anythig else comes
up :).

George

Closing the bug, as resolved and tested and no complaints within a week (still
~
in ppc, but I'll let ppc people remove it).

George