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 attachment 4558 [details, diff] 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 attachment 4686 [details] modified ebuild
Created attachment 4687 [details, diff] 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
