[issue3367] Uninitialized value read in parsetok.c

STINNER Victor added the comment: I close the issue, it has been fixed. I'm no longer able to reproduce the initial issue: $ ./configure --with-pydebug --with-valgrind $ make clean $ make $ valgrind --suppressions=Misc/valgrind-python.supp ./python ==2670== Memcheck, a memory error detecto

[issue3367] Uninitialized value read in parsetok.c

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue3367] Uninitialized value read in parsetok.c

Mark Lawrence added the comment: The fix proposed by Alexander in issue3367.diff has never been applied. How would I go about reproducing the original issue on Windows? -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python t

[issue3367] Uninitialized value read in parsetok.c

Changes by A.M. Kuchling : -- nosy: -akuchling ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue3367] Uninitialized value read in parsetok.c

Changes by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: Serhiy, probably a false positive: https://bugs.kde.org/show_bug.cgi?id=298281 -- ___ Python tracker ___ __

[issue3367] Uninitialized value read in parsetok.c

Serhiy Storchaka added the comment: I see a crash with valgring even without hitting Ctrl-D. $ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python ==26172== Memcheck, a memory error detector ==26172== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==26172=

[issue3367] Uninitialized value read in parsetok.c

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3367] Uninitialized value read in parsetok.c

Meador Inge added the comment: I can still reproduce the parsetok.c problem on the 'default' branch using the CTRL+D method Stefan described. -- ___ Python tracker ___ _

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: I think the original issue in parsetok.c is still present. The fix that was committed was for sys_update_path(). -- ___ Python tracker ___

[issue3367] Uninitialized value read in parsetok.c

Brett Cannon added the comment: Should this be closed? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue3367] Uninitialized value read in parsetok.c

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: You are right, Stefan, argv[argc] is defined to be NULL by the standard. Jolly good. -- ___ Python tracker ___ ___

[issue3367] Uninitialized value read in parsetok.c

Roundup Robot added the comment: New changeset c0900fd6e4b3 by Stefan Krah in branch '3.2': Issue #3367: NULL-terminate argv[] copies to prevent an invalid access http://hg.python.org/cpython/rev/c0900fd6e4b3 New changeset 1ab8fa2277d9 by Stefan Krah in branch 'default': Issue #3367: Merge fix

[issue3367] Uninitialized value read in parsetok.c

STINNER Victor added the comment: > I'm sure you didn't intend to use words such as "wrong" and "useless" Victor. >  Perhaps n must be 0 even for argc>0, but I did that as an afterthought. If n is initialized as wcslen(argv[0]), test_cmd_line_script fails. --

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: K&R page 115 also says: The standard requires that argv[argc] be a NULL pointer. So it must be in C89 as well. -- ___ Python tracker ___ __

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: I only have the C99 standard. It says [5.1.2.2.1]: - argv[argc] shall be a NULL pointer. Is this different in C89? Also, my patch terminates the *copies* of argv, not argv itself. -- ___ Python tracker

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: I'm sure you didn't intend to use words such as "wrong" and "useless" Victor. Perhaps n must be 0 even for argc>0, but I did that as an afterthought. Which is the reason I asked you to take a look rather than committing this right away. Please allow

[issue3367] Uninitialized value read in parsetok.c

STINNER Victor added the comment: Kristján's patch is wrong: n should be set to 0 even if argc > 0. The patch is also useless with argv-alloc.diff. @Stefan: Your patch is correct and solves the issue. You can commit it to 2.7, 3.2 and 3.3. -- ___ Py

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: > 3) line 1812 assumes n to be equal to the length of arg0, but depending > > on conditional compilation, it may not get set at all, and in any> > case in line line 1805 it gets set only if p is not NULL. n is initialized to 0 when its declared. I thin

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: It's the line argv0 = argv[0] in sys_update_path(). The copies of argv made in python.c aren't NULL terminated. Kristján's patch worked around that (and fixes the problem), but I'd prefer to make a full copy of argv in python.c. Could one of you look at the patch?

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: I don't quite understand what you're saying about line mismatch Victor. Anyway, if you look at it, it is clear that: 1) sys_update_path() can be called with argc==0 (main.c line 647) 2) 1742 was always setting arg0 to argv[0] that is undefined and this a

[issue3367] Uninitialized value read in parsetok.c

STINNER Victor added the comment: > Stephan: can you redo the Valgrind test on copy the exact line > where the invalid read occurs (in sysmodule.c). Oops: ... *and* copy the exact line ... -- ___ Python tracker __

[issue3367] Uninitialized value read in parsetok.c

STINNER Victor added the comment: I'm unable to reproduce this error: -- $ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python Python 3.3.0a1+ (default:0554183066b5, Mar 20 2012, 10:47:41) ... ==20258== Invalid read of size 8 ==20258==at 0x4C9F6F: sys_update_

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: Victor, could you check out the last patch here for sysmodule? I gather that you are familiar with it. -- nosy: +haypo ___ Python tracker

[issue3367] Uninitialized value read in parsetok.c

Changes by Kristján Valur Jónsson : -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: Here is a patch for the sysmodule.c problem -- Added file: http://bugs.python.org/file24983/sysmodule.patch ___ Python tracker ___ _

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: It isn't fixed. Also, there's now an additional invalid read in sys_update_path(): $ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python ==20258== Memcheck, a memory error detector ==20258== Copyright (C) 2002-2010, and GNU GPL'd, by Julian

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson added the comment: bump, what is the status of this? Was it fixed? -- ___ Python tracker ___ ___ Python-bugs-l

[issue3367] Uninitialized value read in parsetok.c

Changes by Alexander Belopolsky : -- assignee: georg.brandl -> belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue3367] Uninitialized value read in parsetok.c

Alexander Belopolsky added the comment: On Fri, Feb 4, 2011 at 11:35 AM, Georg Brandl wrote: >.. But seeing the history of this case, I don't want to play around here >before 3.2 final. Here is my understanding of the history of this case: tmp1.patch was applied in r65539 and reverted in r6

[issue3367] Uninitialized value read in parsetok.c

Georg Brandl added the comment: No need to bump the version, it can go into 3.2.1. But seeing the history of this case, I don't want to play around here before 3.2 final. -- ___ Python tracker ___

[issue3367] Uninitialized value read in parsetok.c

Alexander Belopolsky added the comment: George, This is not really important enough to get into the 3.2 release, but uninitialized variable bugs tend to be nasty when they bite you, so I'll ask your opinion before bumping the version. -- assignee: -> georg.brandl nosy: +georg.brandl

[issue3367] Uninitialized value read in parsetok.c

Alexander Belopolsky added the comment: I don't have a working valgrind or purify, but I was able to reproduce the problem using a poor man's solution of adding assert(0xcbcbcbcbcbcbcbcb != tok->line_start); before if (a >= tok->line_start) With that assert the debug buil

[issue3367] Uninitialized value read in parsetok.c

Stefan Krah added the comment: I can still reproduce it in py3k just by hitting Ctrl-D in the interactive interpreter: $ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python ==16724== Memcheck, a memory error detector ==16724== Copyright (C) 2002-2009, and GNU GPL'd, by

[issue3367] Uninitialized value read in parsetok.c

Benjamin Peterson added the comment: Excellent! -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue3367] Uninitialized value read in parsetok.c

Changes by Meador Inge : Added file: http://bugs.python.org/file16021/revert-76139-76689.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue3367] Uninitialized value read in parsetok.c

Meador Inge added the comment: I think this was fixed with checkins r76689 and r76230, made by Benjamin. Since we are using "exec ''" as the reproduction case, the token state is setup in 'PyTokenizer_FromString', which causes 'tok->inp == ""'. The code before these checkins (see attached re

[issue3367] Uninitialized value read in parsetok.c

Daniel Diniz added the comment: Confirmed in trunk: ~/trunk-py$ ./configure --with-pydebug --without-pymalloc && make [...] ~/trunk-py$ valgrind --suppressions=Misc/valgrind-python.supp ./python ==29730== Memcheck, a memory error detector. [...] Python 2.7a0 (trunk:72608M, May 16 2009, 17:31:09)

[issue3367] Uninitialized value read in parsetok.c

Daniel Diniz added the comment: According to issue 1562308, "exec ''" is enough to reproduce this. -- nosy: +ajaksu2 stage: -> test needed versions: -Python 2.5 ___ Python tracker

[issue3367] Uninitialized value read in parsetok.c

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Ok, un-targetting it from 2.5.3 for now. -- versions: -Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3367] Uninitialized value read in parsetok.c

Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment: Now that the 'easy' keyword is absent, I'm afraid this is out of my depth. I'll run purify again and try to find the exact repro case. ___ Python tracker <[EMAIL PROTECTED]>

[issue3367] Uninitialized value read in parsetok.c

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Kristján, you suggested this patch to be considered for 2.5.3. It seems the patch is incorrect. Can you provide a correct one? -- nosy: +loewis versions: +Python 2.5.3 ___ Python tracker <[EMAIL

[issue3367] Uninitialized value read in parsetok.c

A.M. Kuchling <[EMAIL PROTECTED]> added the comment: This patch was applied in rev. 65539, but then reverted; it turns out to break Lib/test/test_parser.py. The exception is: raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_parser

[issue3367] Uninitialized value read in parsetok.c

Changes by Brett Cannon <[EMAIL PROTECTED]>: -- priority: -> high ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue3367] Uninitialized value read in parsetok.c

Changes by Brett Cannon <[EMAIL PROTECTED]>: -- nosy: +brett.cannon ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mail

[issue3367] Uninitialized value read in parsetok.c

Changes by Kristján Valur Jónsson <[EMAIL PROTECTED]>: -- versions: +Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bu

[issue3367] Uninitialized value read in parsetok.c

New submission from Kristján Valur Jónsson <[EMAIL PROTECTED]>: If a PyTokenizer_FromString() is called with an empty string, the tokenizer's line_start member never gets initialized. Later, it is compared with the token pointer 'a' in parsetok.c:193 and that behavior can result in undefined