Marc-Andre Lemburg <m...@egenix.com> added the comment: Stefan Krah wrote: > > New submission from Stefan Krah <stefan-use...@bytereef.org>: > > Not sure if this is valid or if there is some internal trickery that Valgrind > isn't aware of. If it's the latter, perhaps an entry to > Misc/valgrind.supp could be added. > > > test_bug1175396 (__main__.UTF32Test) ... ==26861== Conditional jump or move > depends on uninitialised value(s) > ==26861== at 0x48A2DD: PyUnicodeUCS2_DecodeUTF32Stateful > (unicodeobject.c:2282) > ==26861== by 0x50E25C: utf_32_le_decode (_codecsmodule.c:420) > ==26861== by 0x52E727: PyCFunction_Call (methodobject.c:81) > ==26861== by 0x4B4EB7: call_function (ceval.c:4012) > ==26861== by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665) > ==26861== by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252) > ==26861== by 0x4B52C0: fast_function (ceval.c:4108) > ==26861== by 0x4B4FE1: call_function (ceval.c:4033) > ==26861== by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665) > ==26861== by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252) > ==26861== by 0x4B52C0: fast_function (ceval.c:4108) > ==26861== by 0x4B4FE1: call_function (ceval.c:4033) > ==26861== > ==26861== > ==26861== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y > ==26861== starting debugger with cmd: /usr/bin/gdb -nw /proc/26862/fd/1014 > 26862 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu"... > Attaching to program: /proc/26862/fd/1014, process 26862 > 0x000000000048a2dd in PyUnicodeUCS2_DecodeUTF32Stateful (s=0x5bd6a54 "\n", > size=1, errors=0x5add144 "strict", byteorder=0x7feffb18c, > consumed=0x7feffb170) at Objects/unicodeobject.c:2282 > 2282 if (qq[iorder[2]] != 0 || qq[iorder[3]] != 0) > (gdb) p s > $1 = 0x5bd6a54 "\n" > (gdb) p qq > $2 = (const unsigned char *) 0x5bd6a54 "\n" > (gdb) p iorder[2] > $3 = 2 > (gdb) p iorder[3] > $4 = 3 > (gdb) p bo > $5 = -1 > (gdb) p *byteorder > $6 = -1
Could you check whether the report goes away when using the following definition of iorder in that function: #ifdef BYTEORDER_IS_LITTLE_ENDIAN const int iorder[4] = {0, 1, 2, 3}; #else const int iorder[4] = {3, 2, 1, 0}; #endif I guess that the missing dimension is causing the valgrind report. >From a code perspective, everything is in order, in fact I'd expect the compiler to optimize the array away. It may even be a good idea to replace the array with symbols: #ifdef BYTEORDER_IS_LITTLE_ENDIAN # define BYTEORDER_0 0 # define BYTEORDER_1 1 # define BYTEORDER_2 2 # define BYTEORDER_3 3 #else # define BYTEORDER_0 3 # define BYTEORDER_1 2 # define BYTEORDER_2 1 # define BYTEORDER_3 0 #endif ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9242> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com