Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

C::B segfault on startup (~2387)

<< < (2/2)

tiger683:

--- Quote from: mandrav on May 05, 2006, 01:57:02 pm ---
--- Quote from: tiger683 on May 05, 2006, 12:57:57 pm ---Any progress with this one?


--- End quote ---

What progress? It works just fine in any 32bit distro I tested it (scripting is not supported for 64bit currently), I can't see any errors. I don't have a Gentoo system to test though nor can I provide support for ebuilds (don't know about them), sorry.

--- End quote ---

Thanks for fast reply.

Then i guess i'll just dig into the code myself (since i use C::B for my current project and update C::B pretty often, it is worth spending these few moments on fixing it).
Thanks for your hard work :)

Regards,

Rafael

tiger683:
This seems to be a CXXFLAGS problem.
I added a flag-stripping directive into the ebuild in my overlay
and now the problem seems to be gone (I can start C::B with wizard enabled :D)

Could anyone confirm or neglect that the -fvisibility-inlines-hidden cxxflag causes such misbehaviour?
I'll test this myself too, but maybe someone has a faster machine to recompile and look for breakage.
EDIT: This would in particular be useful to just filter THE offending flag instead of stripping them all :]

mandrav, sorry for wasting your time with bugging you about this problem  :?

Thanks for an awesome IDE,

T

polygon7:
Hi,
i removed
--- Quote ----fvisibility-inlines-hidden
--- End quote ---
flag, and C::B still segfault in copyloop(). I will check other flags.

tiger683:

--- Quote from: polygon7 on May 11, 2006, 06:31:53 pm ---Hi,
i removed
--- Quote ----fvisibility-inlines-hidden
--- End quote ---
flag, and C::B still segfault in copyloop(). I will check other flags.

--- End quote ---

Now, who would have thought...
I went through everything i did before it started working and guess what...the problem is NOT C::B itself!
The winner of this puzzle is revealed by this cute little backtrace:

--- Code: ("gdb") ---(gdb) next
[New Thread -1241998432 (LWP 16121)]

Program received signal SIGSEGV, Segmentation fault.
0xb71f55df in inflateBack () from /lib/libz.so.1
(gdb) bt
#0  0xb71f55df in inflateBack () from /lib/libz.so.1
#1  0xbfe32c68 in ?? ()
#2  0xb7ab4411 in operator delete () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-pre20060223/libstdc++.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)

--- End code ---

So, stack corruption in call to a zlib function...huh...
It gets even better, if you recompile zlib _WITHOUT_ the -ftree-vectorize CFLAG (no, not CXXFLAG :P),
C::B will start without a problem  :shock: . Strange enough but worksforme :P
I knew there was something about the vectorizer, that's why i switched it off a while after having compiled my system...
but also after having compiled zlib last time  :lol:

I hope it helps you too ;)

Thanks

T

polygon7:
I dont use -ftree-vectorize. I found bogus flag in my case: -fomit-frame-pointer. I removed this flag and now C::B run without problems. Strange thing is that flag works for older versions. Maybe somebody know why this flag triggers segfault?

Navigation

[0] Message Index

[*] Previous page