Bugzilla Bug 65752

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 an attachment (id=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 an attachment (id=41704) [details]
src/Synth/OscilGen.s: OscilGen::prepare() / gcc 3.3.4

-O0 -Wall -S

Created an attachment (id=41705) [details]
src/Synth/OscilGen.s: OscilGen::prepare() / 3.4.2

-O0 -Wall -S

Created an attachment (id=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 an attachment (id=41757) [details]
src/Synth/OscilGen.s: gcc 3.4.2

g++ -O0 -S    -c -o OscilGen.s OscilGen.C

Created an attachment (id=41759) [details]
src/Synth/OscilGen.s: gcc 3.3.4

g++ -O0 -S    -c -o OscilGen.s OscilGen.C

Created an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.