* Sebastian Siebert [2010-11-21 11:02]:

Hi again,

I have identify an issue with an option "-D_FORTIFY_SOURCE=2" in the CFLAGS for GCC 4.x. There is a variable called "%{optflags}" in the spec file and it includes the option "-D_FORTIFY_SOURCE=2".

The configure script try to reset the option "-D_FORTIFY_SOURCE=2" to "-D_FORTIFY_SOURCE=1" in CFLAGS. But the reset of CFLAGS option is without effect. It compile with the option "-D_FORTIFY_SOURCE=2" again.

Now I use a sledgehammer in the spec file:

export CFLAGS=`echo "$CFLAGS" | sed -e 's/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=1/g'`

After that, everything works fine.

Is there any other solution other than the sledgehammer?

Yes, check out the source code at the specified locations whether there is a potential buffer overflow, the GCC compile time buffer checks are activated for a reason. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

* Sebastian Siebert [2010-11-21 12:31]:

Am 21.11.2010 11:35, schrieb Guido Berhoerster:

...

* Sebastian Siebert [2010-11-21 11:02]: [...]

...

Is there any other solution other than the sledgehammer?

Yes, check out the source code at the specified locations whether there is a potential buffer overflow, the GCC compile time buffer checks are activated for a reason.

Hm, the upstream thinks that is a problem of gcc: http://www.mail-archive.com/vim_dev@googlegroups.com/msg04786.html

vim seems to use some clever optimizations for memory management which break with -D_FORTIFY_SOURCE=2 so in this case it seems justified to replace it with -D_FORTIFY_SOURCE=1 as recommended by upstream. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 21/11/10 09:16, Guido Berhoerster escribió:

vim seems to use some clever optimizations for memory management which break with -D_FORTIFY_SOURCE=2 so in this case it seems justified to replace it with -D_FORTIFY_SOURCE=1 as recommended by upstream.

In case this code is really correct (?) only the affected unit, may be built with "1" NOT the whole package ! #ifdef _FORTIFY_SOURCE #undef _FORTIFY_SOURCE #define _FORTIFY_SOURCE 1 #endif ps: yeah, I should not be teaching on how to do this stuff, it is dangerous ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11/21/2010 03:02 PM, Cristian Rodríguez wrote:

El 21/11/10 09:16, Guido Berhoerster escribió:

...

vim seems to use some clever optimizations for memory management which break with -D_FORTIFY_SOURCE=2 so in this case it seems justified to replace it with -D_FORTIFY_SOURCE=1 as recommended by upstream.

In case this code is really correct (?) only the affected unit, may be built with "1" NOT the whole package !

#ifdef _FORTIFY_SOURCE #undef _FORTIFY_SOURCE #define _FORTIFY_SOURCE 1 #endif

ps: yeah, I should not be teaching on how to do this stuff, it is dangerous ;-)

Thanks, now it's fallen into the wrong hands :-) I had a package that failed (gcc froze) on one lib when anything more than -o0 was used, that would have been easier than patching SConscript. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11/21/2010 03:25 PM, Cristian Rodríguez wrote:

El 21/11/10 10:22, Dave Plater escribió:

...

Thanks, now it's fallen into the wrong hands :-)

:-)

...

I had a package that failed (gcc froze) on one lib when anything more than -o0 was used, that would have been easier than patching SConscript. Dave P

FORTIFY_SOURCE has nothing to do with optimization...if GCC freezes then there is a bug in the compiler..

I blinked and saw the -D in -D_FORTIFY_SOURCE pity it won't work with -o0 :-! . COLLADASaxFrameworkLoader which won't build with > -o0 won't build on my local system with -j 2 either, it goes "out of memory". I've initialized a build in home:plater:blender > openCOLLADA with -o2 and after hanging for 1/2 hour it's on : g++ -o COLLADASaxFrameworkLoader/obj/posix/x86_64/debuglibxml/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateNameMap.os -c -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -ggdb -DGENERATEDSAXPARSER_XMLPARSER_LIBXML -DGENERATEDSAXPARSER_VALIDATION -fPIC -ICOLLADASaxFrameworkLoader/include -ICOLLADASaxFrameworkLoader/include/generated14 -ICOLLADASaxFrameworkLoader/include/generated15 -ICOLLADABaseUtils/include -IGeneratedSaxParser/include -ICOLLADAFramework/include -IExternals/MathMLSolver/include -IExternals/MathMLSolver/include/AST -I/usr/include/libxml2 COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateNameMap.cpp COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateFunctionMap.cpp: In member function 'void COLLADASaxFWL14::ColladaParserAutoGen14Private::initFunctionMap()': COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateFunctionMap.cpp:20:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without If this happens is it a bug or does it justify -o0? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11/22/2010 12:36 PM, Richard Guenther wrote:

On Mon, 22 Nov 2010, Dave Plater wrote:

...

On 11/21/2010 03:25 PM, Cristian Rodríguez wrote:

...

El 21/11/10 10:22, Dave Plater escribió:

...

Thanks, now it's fallen into the wrong hands :-)

:-)

...

I had a package that failed (gcc froze) on one lib when anything more than -o0 was used, that would have been easier than patching SConscript. Dave P

FORTIFY_SOURCE has nothing to do with optimization...if GCC freezes then there is a bug in the compiler..

I blinked and saw the -D in -D_FORTIFY_SOURCE pity it won't work with -o0 :-! . COLLADASaxFrameworkLoader which won't build with > -o0 won't build on my local system with -j 2 either, it goes "out of memory". I've initialized a build in home:plater:blender > openCOLLADA with -o2 and after hanging for 1/2 hour it's on :

g++ -o COLLADASaxFrameworkLoader/obj/posix/x86_64/debuglibxml/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateNameMap.os -c -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -ggdb -DGENERATEDSAXPARSER_XMLPARSER_LIBXML -DGENERATEDSAXPARSER_VALIDATION -fPIC -ICOLLADASaxFrameworkLoader/include -ICOLLADASaxFrameworkLoader/include/generated14 -ICOLLADASaxFrameworkLoader/include/generated15 -ICOLLADABaseUtils/include -IGeneratedSaxParser/include -ICOLLADAFramework/include -IExternals/MathMLSolver/include -IExternals/MathMLSolver/include/AST -I/usr/include/libxml2 COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateNameMap.cpp COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateFunctionMap.cpp: In member function 'void COLLADASaxFWL14::ColladaParserAutoGen14Private::initFunctionMap()': COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateFunctionMap.cpp:20:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without

If this happens is it a bug or does it justify -o0?

*sigh*

Can you open a bug and attach preprocessed source? -fno-var-tracking should fix it as well (hopefully).

Richard.

I'll try -fno-var-tracking but -o0 works fine as well. The developers had set -o0 for that particular library anyway. Is -o0 not allowed because -o2 produces other problems with OpenCOLLADASaxFrameworkLoader build as well? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 21/11/10 10:22, Dave Plater escribió:

Thanks, now it's fallen into the wrong hands :-) I had a package that failed (gcc froze) on one lib when anything more than -o0

Ohh I see you confused the "1" in my post, thinking Im talking about "-O1" ..no.. Im talking about _FORTIFY_SOURCE=1 in case you need a particular function to be built with less optimization, you can use __attribute__((optimize("1"))) or #pragma GCC optimize .. *grin* -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 21/11/10 11:34, Sebastian Siebert escribió:

I would be glad if someone can look into the source code.

I sent submit request #53627 to your project with a possible workaround, but.. if it messes stuff up, dont look at me ! it wasnt me! :P The code is fundamentally, crazy. After looking at this, Im reconsidering my choice of editor.. ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi all, thank you all very much for your help and for the interesting solutions. Am 22.11.2010 07:55, schrieb Cristian Morales Vega:

2010/11/22 Cristian Rodríguez:

...

El 21/11/10 11:34, Sebastian Siebert escribió:

...

I would be glad if someone can look into the source code.

I sent submit request #53627 to your project with a possible workaround, but.. if it messes stuff up, dont look at me ! it wasnt me! :P

The code is fundamentally, crazy.

I would not really touch it. The code is "good"*, there is no real overflows since there are 21 bytes of space at destination and the biggest offender is 5 bytes. The code comments make clear they know they were doing it... but it fails to explain why it was done that way, But I expect them to have a good cause. Hey, they are playing with functions pointer in that part of the code...

The funny thing is that gcc is only complaining about the STRCPYs that have this comment before:

/* Set l:self to "selfdict". Use "name" to avoid a warning from * some compiler that checks the destination size. */

It seems that with name = v->di_key; STRCPY(name, "self"); gcc fails to see the extra space, but with STRCPY(v->di_key, "self"); the warning would dissapear (I didn't test).

Apparently those changes were made because of the crash reported in the vim_dev mail Sebastian linked before. So... IMHO your "#ifdef _FORTIFY_SOURCE" fix would be the better.

* At http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38136#c5 it's said the code violates 6.7.2.1/2 from C99. But it's my understanding that since it uses "di_key[1]" instead of "di_key[]" it's OK.

Thank you for this clear statement. In fact, the solution "#ifdef _FORTIFY_SOURCE" is the better way to tell the compiler to restrict only onto the code of eval.c. I submit the updated files to my home repository and now the build service is happy: ;-) https://build.opensuse.org/package/show?package=vim&project=home%3AFreespacer%3Abranches%3Aeditors Okay, I have submitted the request to obs://editors/vim then we'll see further. :-) -- Kind regards, Sebastian - openSUSE Member (Freespacer) Website/Blog: http://www.sebastian-siebert.de Important notes on openSUSE Mailing List: http://en.opensuse.org/OpenSUSE_mailing_list_netiquette -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sun, 21 Nov 2010 22:50:20 -0300 Cristian Rodríguez wrote:

The code is fundamentally, crazy.

After looking at this, Im reconsidering my choice of editor.. ;)

Exactly what I was doing when I saw this piece of "art"... -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 21/11/10 07:44, Stefan Seyfried escribió:

Alternatively, prove to the gcc guys that their check is wrong and the buffer is actually *not* overflowing, so that they can fix the compiler.

AFAIK It is actually overflowing ;) the code should be fixed. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org