Zyn crashes when you send midi data to it, after being compiled with gcc 3.4.2-r2 nothing else changed, i simply switched compilers with 'gcc-config' to 3.3.4, recompiled Zyn, and it works. backtrace: http://paste.phpfi.com/31482 i even tried patching the Zyn makefile to use sensible compiler flags, but there was no change in behavior (still crashed).
need emerge info when was gcc-3.4.2-r2 merged? if not after Sept. 21st, please remerge
Created attachment 40681 [details] emerge --info
remerged gcc 3.4.2-r2, remerged zyn with it. no change in behavior. zyn loads, then when you send midi data or try to play the virtual keyboard, crash! it's gotta be a compiler bug. no crash happens if you gcc-config to a 3.3.x compiler to emerge zyn
maybe it's just me and thom having this problem? i'm thinking, "glibc bug" anyways leave this bug open until the next glibc is available in the tree, in case someone else besides thom and i experience trouble. the work around if you run into this is to compile your zyn with gcc 3.3.4
confirmed by 3 other people. cause is ? no idea. amd64 and ~x86
more info coming. newer version of Zyn brings forth the same flaw in GCC 3.4.2, and i have some assembler code to share. compiled with -O0 -S -Wall flags.
Created attachment 41704 [details] src/Synth/OscilGen.s: OscilGen::prepare() / gcc 3.3.4 -O0 -Wall -S
Created attachment 41705 [details] src/Synth/OscilGen.s: OscilGen::prepare() / 3.4.2 -O0 -Wall -S
Created attachment 41707 [details] src/Synth/OscilGen.C: OscilGen::prepare() source code portion from media-sound/zynaddsubfx
relevent part that seems to be dying from bad gcc 3.4.x generation is line 32-33 of the ::prepare function in OscilGen.C, no matter what you put after those 'for' statements it is corrupted and dies inexplicably.
Created attachment 41757 [details] src/Synth/OscilGen.s: gcc 3.4.2 g++ -O0 -S -c -o OscilGen.s OscilGen.C
Created attachment 41759 [details] src/Synth/OscilGen.s: gcc 3.3.4 g++ -O0 -S -c -o OscilGen.s OscilGen.C
Created attachment 41763 [details] src/Synth/OscilGen.C when built with these flags... CXXFLAGS= -O0 -ggdb -Wall ...and the gcc 3.3.4-r1 compiler, the program operates normally. when built with the same flags and the gcc 3.4.2-r1 compiler, the program loads but crashes when trying to run the part of the code that generates the Additive Synthesis. The invalid code appears in the "OscilGen::prepare" function, at line 677 of the OscilGen.C source code.
Created attachment 41764 [details] gdb output from zynaddsubfx crash compiled w/ 3.4.2-r2, ran zyn the first time and enabled only the SUBSynth = no crash, then enabled the PADsynth = crash, ran zyn a second time and enabled only the ADSynth = crash
Created attachment 41766 [details] diff -burN OscilGen-OscilGen_prepare.s-3.3.4 OscilGen-OscilGen_prepare.s-3.4.2 diff of assembler output pertaining to the relevent problematic compiler output, in the OscilGen::prepare function.
gcc folks said it was not likely a gcc bug. i'm not so sure about that, but they suggested using valgrind and some other tricks to get a better idea. valgrind blew up, and refused to get farther than a "generic error" in libc. for now, i think i've found a workaround; it is ugly, doesn't make any sense, and if there is indeed some sort of problem with the Zyn code i would rather get the source of the problem solved. closing this bug as CANTFIX because i have nfc how to find the memory problem in the code. there's just too many "x-y-z" operator precedence assumptions where i do not know what the author intended, or why this code ever worked when compiled with gcc 3.4.2 anyways.
according to the gcc guys on IRC, this is not a problem with gcc / glibc / kernel and parts of the official specifications not being real clear on how to do memory alignement for operator :: new.
Created attachment 41778 [details] IRC session, #gcc on OFTC conversation, detailing how this is some kind of gcc/glibc related bug, possibly an alignement issue.
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
this is a gcc bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990). closing.
