homepage

When running python2.5 under valgrind and running
 exec ""
valgrind issues the following warning:
==6661== Conditional jump or move depends on
uninitialised value(s)
==6661== at 0x403EAF3: parsetok (parsetok.c:189)
==6661== by 0x40ED673: PyParser_ASTFromString
(pythonrun.c:1354)
==6661== by 0x40EF852: PyRun_StringFlags
(pythonrun.c:1225)
==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202)
==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494)
==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags
(pythonrun.c:1264)
==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags
(pythonrun.c:714)
==6661== by 0x40EF6CA: PyRun_AnyFileExFlags
(pythonrun.c:683)
==6661== by 0x40F930D: Py_Main (main.c:496)
==6661== by 0x8048591: main (in /usr/bin/python2.5)
Valgrind does not give warnings when doing the same
thing with python2.4.3.
After further investigation, it looks like
tok->line_start is uninitialized. Initializing to null
in tok_new() removes the valgrind warning, but I have
no idea if this is the correct fix.

Logged In: YES 
user_id=33168
Thanks for the report.
What is the python code that caused this warning to be
generated? I've run valgrind with the standard tests and
don't recall this error. Without looking at the code, the
proposed fix seems to make sense (though from the name, I
would have guessed that line_start is an int rather than a
pointer).
Also, what system and compiler are you using and how did you
build python?

Logged In: YES 
user_id=1437974
Running the python statement
 exec ""
in the interactive shell will trigger the warning for me.
I'm running Debian unstable, and can reproduce the problem
with its RC1 python2.5 package built with gcc 4.1:
Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29)
[GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2
I can also reproduce the problem with my own build of the
official 2.5 release with built gcc 4.0:
Python 2.5 (r25:51908, Sep 19 2006, 15:38:29)
[GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2

Logged In: YES 
user_id=33168
The proposed fix should be made, but I can't reproduce the
problem. That bugs me. I'm running valgrind 3.2.0, what
version are you running? I tried with gcc 3.3.x on x86 and
gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo.
Have you run the entire regression suite with valgrind? I
did, but given I'm not seeing these problems, I wonder if
there might be issues lurking. 

Logged In: YES 
user_id=1437974
For me, the output of 'valgrind --version' is
valgrind-3.2.0-Debian.
I get warnings from some tests when I run the test suite
under valgrind. When I ran the tests, I uncommented the
first block of ###-commented suppressions in
valgrind-python.supp and ran:
 valgrind --tool=memcheck
--suppressions=Misc/valgrind-python.supp --quiet ./python -E
-tt ./Lib/test/regrtest.py -u bsddb,network
(Note that I can reproduce the warning I'm seeing the
valgrind-python.supp suppressions file.)
The test suite warnings I get are:
test_asynchat
==2425== Thread 2:
==2425== Conditional jump or move depends on uninitialised
value(s)
==2425== at 0x415F09C: __pthread_manager (manager.c:128)
==2425== by 0x4291309: clone (clone.S:119)
==2425==
==2425== Syscall param clone(child_tidptr) contains
uninitialised byte(s)
==2425== at 0x42912FC: clone (clone.S:100)
==2425== by 0x4291309: clone (clone.S:119)
test_capi
==2420==
==2420== Thread 1:
==2420== Syscall param write(buf) points to uninitialised
byte(s)
==2420== at 0x415E4AF: pthread_detach (join.c:216)
==2420== by 0x40F6BCA: PyThread_start_new_thread
(thread_pthread.h:197)
==2420== by 0x4E82952: test_thread_state
(_testcapimodule.c:663)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== Address 0xAEB75F74 is on thread 1's stack
test_codecs
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x40A445F: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:2395)
==2420== by 0x410D796: unicode_internal_decode
(_codecsmodule.c:225)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords
(ceval.c:3435)
==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377)
==2420== by 0x4084FD3: PyString_AsDecodedObject
(stringobject.c:391)
==2420== by 0x4086A92: string_decode (stringobject.c:3260)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x40A0F30: unicode_resize (unicodeobject.c:188)
==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250)
==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:2383)
==2420== by 0x410D796: unicode_internal_decode
(_codecsmodule.c:225)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords
(ceval.c:3435)
==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377)
==2420== by 0x4084FD3: PyString_AsDecodedObject
(stringobject.c:391)
==2420== by 0x4086A92: string_decode (stringobject.c:3260)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420==
==2420== Use of uninitialised value of size 4
==2420== at 0x40A0F32: unicode_resize (unicodeobject.c:188)
==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250)
==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:2383)
==2420== by 0x410D796: unicode_internal_decode
(_codecsmodule.c:225)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords
(ceval.c:3435)
==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377)
==2420== by 0x4084FD3: PyString_AsDecodedObject
(stringobject.c:391)
==2420== by 0x4086A92: string_decode (stringobject.c:3260)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
test_codeop
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x403EAF3: parsetok (parsetok.c:189)
==2420== by 0x40ED673: PyParser_ASTFromString
(pythonrun.c:1354)
==2420== by 0x40ED793: Py_CompileStringFlags
(pythonrun.c:1311)
==2420== by 0x40C043A: builtin_compile (bltinmodule.c:464)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
test_ctypes
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x40692E5: PyInt_FromLong (intobject.c:87)
==2420== by 0x6B12F18: l_get (cfield.c:810)
==2420== by 0x6B0FC8A: _CallProc (callproc.c:740)
==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420==
==2420== Use of uninitialised value of size 4
==2420== at 0x6B15703: ffi_call (ffi.c:237)
==2420== by 0x6B0FADE: _CallProc (callproc.c:665)
==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420==
==2420== Use of uninitialised value of size 4
==2420== at 0x6B15706: ffi_call (ffi.c:237)
==2420== by 0x6B0FADE: _CallProc (callproc.c:665)
==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
test_gzip
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x52DC1CA: longest_match (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DCEB0: deflate_slow (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DD6BF: deflate (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x52DC153: longest_match (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DCEB0: deflate_slow (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DD6BF: deflate (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420==
==2420== Conditional jump or move depends on uninitialised
value(s)
==2420== at 0x52DC18E: longest_match (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DCEB0: deflate_slow (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52DD6BF: deflate (in
/home/luke/dev/hfs/dsolib/libz.so.1.2.3)
==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605)
==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108)
==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652)
==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833)
==2420== by 0x4067C59: function_call (funcobject.c:517)
==2420== by 0x4045066: PyObject_Call (abstract.c:1860)
==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846)

Logged In: YES 
user_id=33168
The ones complaining about pthread (test_asynchat,
test_capi) are not a problem. test_codecs is worrisome. I
don't believe test_ctypes is a problem and I'm guessing that
the test_gzip problem is either due to test_ctypes or an
internal gzip library problem. BTW, you might want to read
Misc/README.valgrind if you haven't already. You also need
to skip test_socket_ssl as that causes a bunch of
uninitialized memory warnings due to the SSL library.
Thanks for the reports, I'll try to take a look at them later.

Seems to be the same as issue 3367, but Kristján forgot his repro case
there.

This is the same as 3367, which Benjamin just closed out.