[issue1608] test_str.py crashes

2008-01-09 Thread Guido van Rossum
Guido van Rossum added the comment: It would actually be better to use -fno-strict-overflow instead of -fwrapv, if it exists (GCC 4.2 and later). See also http://bugs.python.org/issue1621 which suggests there aren't actually many places that need this; gcc -Wstrict-overflow should help auditing

[issue1608] test_str.py crashes

2007-12-13 Thread Thomas Heller
Thomas Heller added the comment: Guido van Rossum schrieb: > (Thomas, could you run it in the 2.5 branch as well? I seem to have > checked in a lot of gratuitous changes by using an older version of > autoconf.) Done, see rev 59494. __ Tracker <[EMAIL PROTECTED]

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: > """code that has been audited and fixed in the past will again be > vulnerable.""" > > That code wasn't properly audited or fixed if it depended on integer > overflow behavior. Whatever, this is how overflow checks have been coded all over the code base. __

[issue1608] test_str.py crashes

2007-12-13 Thread Gregory P. Smith
Gregory P. Smith added the comment: """code that has been audited and fixed in the past will again be vulnerable.""" That code wasn't properly audited or fixed if it depended on integer overflow behavior. Anyways, I'm glad we have the flag to disable the optimization on gcc in the meantime. We

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Thomas Heller ran autoconf for the trunk and submitted as r59485. (Thomas, could you run it in the 2.5 branch as well? I seem to have checked in a lot of gratuitous changes by using an older version of autoconf.) -- nosy: +theller resolution: -> fix

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Committed revision 59483 (2.5 branch). Committed revision 59484 (2.6 trunk). Keeping this open since someone still needs to run autoconf to regenerate configure for the 2.6 trunk. -- priority: urgent -> normal __ Track

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Last patch had a grammar error in comment, fix that. Added file: http://bugs.python.org/file8945/wrap.patch __ Tracker <[EMAIL PROTECTED]> __Index: configure.in ==

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Attached patch exactly checks if compiler supports -fwrapv otherwise doesn't use it. Is this ok? Added file: http://bugs.python.org/file8944/wrap.patch __ Tracker <[EMAIL PROTECTED]>

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: GCC 2.96 is still the golden standard for me, and it doesn't like -fwrapv. Please try to come up with a better patch. It should be easy enough to invoke gcc -fwrapv with a dummy program. __ Tracker <[EMAIL PROTECTED]>

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Ok gcc developers say -fwrapv is there since gcc 3.3 so I think its still fine, if not I will prepare another patch. Regards. __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: After applying patch you need to run autoconf to update configure file and svn commit afterwards. Regards, ismail __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Looks like -fwrapv is there since gcc 2.95.3 attached patch adds -fwrapv when debugging disabled, also removes gcc 4.x part from README as it no longer applies. Added file: http://bugs.python.org/file8942/fwrapv.patch __ Tracker <

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Can you suggest a patch that adds this permanently, whenever it is supported? __ Tracker <[EMAIL PROTECTED]> __ ___ P

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: -fwrapv fixes the issue, thanks! __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: > Ok so this is a code bug according to GCC developers see comment 1 & 2 > at http://gcc.gnu.org/PR34454 . I told you you can't win this argument with the GCC devs. We'll have to use -fwrapv or whatever. __ Tracker <[EMAIL PRO

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Ok so this is a code bug according to GCC developers see comment 1 & 2 at http://gcc.gnu.org/PR34454 . __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Reported as a gcc bug, http://gcc.gnu.org/PR34454 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list U

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Following testcase doesn't print overflow with gcc 4.3 when compiled with -O3, works with gcc 3.4.6 though. #include #include void foo(ssize_t x) { if (x >= 0) { if (x+x < 0) printf("Overflow\n"); } } main() { volatile ssize_t x =2147483647; foo(x); }

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Test always prints overflow here, tested with -O3 but here are interesting overflow warnings that might give a clue , but I think Cpickle is not involved here, but anyway: /home/cartman/python-2.5/Modules/cPickle.c: In function 'Unpickler_noload': /home/cartman/p

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: > if you can give me a sample testcase I can bug GCC developers, this > doesn't look good from GCC side at all. Btw from my limited C knowledge > marking variables would volatile would prevent optimizations of them. The example would be something like void fo

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Guido, if you can give me a sample testcase I can bug GCC developers, this doesn't look good from GCC side at all. Btw from my limited C knowledge marking variables would volatile would prevent optimizations of them. __ Tracker <[

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Martin, can you look into this? It seems GCC 4.3 disables buffer overflow protection checks. The best short-term solution may be to disable that particular kind of optimization. How? -- assignee: -> loewis nosy: +loewis ___

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Martin, can you look into this? It seems GCC 4.3 disables buffer overflow protection checks. The best short-term solution may be to disable that particular kind of optimization. How? __ Tracker <[EMAIL PROTECTED]>

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: Indeed you are correct, >>> '\ta\n\tb'.expandtabs(2147483647) Program received signal SIGSEGV, Segmentation fault. string_expandtabs (self=0xb7ba7c60, args=0xb7ba7dec) at Objects/stringobject.c:3358 3358*q++ = ' '; (gdb) bt #0 string_exp

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Actually, looking at the sample code and the string_expandtabs() implementation it's clear what happened: the test for overflow on line 3318 or 3331 or 3339 must have been optimized out by GCC. This is very inconvenient because lots of buffer overflow protecti

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: > This is a soon to be released GCC though I won't deny it has > regressions, but note that extra optimizations already uncovered bugs in > other software. And the GCC authors always win these cases, C standard in hand. > And unless I can get a minimal C test

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: This is a soon to be released GCC though I won't deny it has regressions, but note that extra optimizations already uncovered bugs in other software. And unless I can get a minimal C testcase, GCC bug will be worthless. Exact crashling call is string_tests.py li

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: BTW is this a released version of GCC? If not, you might want to file the bug with the GCC project... __ Tracker <[EMAIL PROTECTED]> __

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: Looks like expandtabs() has a problem. Can you boil it down to a single call? __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Ismail Donmez added the comment: --enable-pydebug fixes the crash it might be that some uninitialized variable doesn't take affect unless optimized as valgrind output shows many of this. __ Tracker <[EMAIL PROTECTED]> ___

[issue1608] test_str.py crashes

2007-12-13 Thread Guido van Rossum
Guido van Rossum added the comment: What hardware and OS? 32 or 64 bit? What optimization level? Debug build or not? NB. Unless you used /Misc/valgrind-python.supp, the valgrind output is useless. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]>

[issue1608] test_str.py crashes

2007-12-13 Thread Ismail Donmez
Changes by Ismail Donmez: -- title: Regression tests crashes with gcc 4.3 -> test_str.py crashes __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu