This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Valgrind memcheck on Py_Initialize
Type: security Stage: resolved
Components: C API, Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: shihai1991, simonaldrich
Priority: normal Keywords:

Created on 2021-04-28 13:53 by simonaldrich, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
valgrind-libpython.tar.gz simonaldrich, 2021-04-28 13:53 Reproducer
Messages (2)
msg392199 - (view) Author: Simon Aldrich (simonaldrich) Date: 2021-04-28 13:53
Running a Valgrind memcheck of Py_Initialize still produces issues even when using the suggested suppressions file. Am I doing something wrong or is this expected?

I've attached a simple reproducer which can be run as follows:

1. Extract tarball
2. cmake
3. make memcheck (runs valgrind with suppressions)

Gives output similar to:

[100%] Built target valgrind-libpython
==2901== Memcheck, a memory error detector
==2901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2901== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2901== Command: ./valgrind-libpython
==2901== 
==2901== Conditional jump or move depends on uninitialised value(s)
==2901==    at 0x5729DB7: __wcsnlen_avx2 (strlen-avx2.S:264)
==2901==    by 0x5657CA1: wcsrtombs (wcsrtombs.c:104)
==2901==    by 0x55DDC40: wcstombs (wcstombs.c:34)
==2901==    by 0x4FB7EB9: _Py_EncodeLocaleRaw (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FB99F7: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FBB8B2: _PyPathConfig_Calculate (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FDAC8D: _PyConfig_InitPathConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE4F6E: PyConfig_Read (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE687A: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE79A1: Py_InitializeFromConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE7A5B: Py_InitializeEx (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x108758: main (in /home/simon/temp/valgrind-libpython/build/valgrind-libpython)
==2901== 
==2901== Conditional jump or move depends on uninitialised value(s)
==2901==    at 0x55C14E8: internal_utf8_loop (loop.c:298)
==2901==    by 0x55C14E8: __gconv_transform_internal_utf8 (skeleton.c:609)
==2901==    by 0x5657CD4: wcsrtombs (wcsrtombs.c:110)
==2901==    by 0x55DDC40: wcstombs (wcstombs.c:34)
==2901==    by 0x4FB7EB9: _Py_EncodeLocaleRaw (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FB99F7: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FBB8B2: _PyPathConfig_Calculate (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FDAC8D: _PyConfig_InitPathConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE4F6E: PyConfig_Read (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE687A: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE79A1: Py_InitializeFromConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE7A5B: Py_InitializeEx (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x108758: main (in /home/simon/temp/valgrind-libpython/build/valgrind-libpython)...
msg398188 - (view) Author: Hai Shi (shihai1991) * (Python triager) Date: 2021-07-25 16:48
Hi, Simon. Thanks for your report.
There have an relatived issue in: bpo-43145, this bpo have mentioned  `Py_Initialize()`. So I suggest to close this bpo. We can reopen it if we have seperated questions need to be discussed in here.

> Running a Valgrind memcheck of Py_Initialize still produces issues even when using the suggested suppressions file. Am I doing something wrong or is this expected?
AFAIK, You are right;)
History
Date User Action Args
2022-04-11 14:59:44adminsetgithub: 88133
2021-07-25 16:48:20shihai1991setstatus: open -> closed

nosy: + shihai1991
messages: + msg398188

resolution: duplicate
stage: resolved
2021-04-28 13:53:21simonaldrichcreate