From patchwork Thu Jun 27 20:33:54 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergio Durigan Junior X-Patchwork-Id: 33465 Received: (qmail 69068 invoked by alias); 27 Jun 2019 20:34:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 69060 invoked by uid 89); 27 Jun 2019 20:34:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=p1, Starting, p4, p7 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Jun 2019 20:33:59 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0EDE81DEB for ; Thu, 27 Jun 2019 20:33:58 +0000 (UTC) Received: from psique.yyz.redhat.com (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 255305C1B4; Thu, 27 Jun 2019 20:33:56 +0000 (UTC) From: Sergio Durigan Junior To: GDB Patches Cc: Sergio Durigan Junior Subject: [PATCH] Fix crash when using PYTHONMALLOC=debug (PR python/24742) Date: Thu, 27 Jun 2019 16:33:54 -0400 Message-Id: <20190627203354.23486-1-sergiodj@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes This bug was originally reported against Fedora GDB: https://bugzilla.redhat.com/show_bug.cgi?id=1723564 The problem is that GDB will crash in the following scenario: - PYTHONMALLOC=debug or PYTHONDEVMODE=1 is set. - The Python debuginfo is installed. - GDB is used to debug Python. The crash looks like this: $ PYTHONMALLOC=debug gdb -args python3 -c pass GNU gdb (GDB) Fedora 8.3-3.fc30 Reading symbols from python3... Reading symbols from /usr/lib/debug/usr/bin/python3.7m-3.7.3-3.fc30.x86_64.debug... (gdb) run Starting program: /usr/bin/python3 -c pass Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-9.fc30.x86_64 Debug memory block at address p=0x5603977bf330: API '' 8098648152243306496 bytes originally requested The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb): at p-7: 0x03 *** OUCH at p-6: 0x00 *** OUCH at p-5: 0x00 *** OUCH at p-4: 0x00 *** OUCH at p-3: 0x00 *** OUCH at p-2: 0x00 *** OUCH at p-1: 0x00 *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 8 pad bytes at tail=0x706483999ad1f330 are Segmentation fault (core dumped) It's hard to determine what happens, but after doing some investigation and talking to Victor Stinner I found that GDB should not use the Python memory allocation functions before the Python interpreter is initialized (which makes sense). However, we do just that on python/python.c:do_start_initialization: ... progsize = strlen (progname.get ()); progname_copy = (wchar_t *) PyMem_Malloc ((progsize + 1) * sizeof (wchar_t)); ... /* Note that Py_SetProgramName expects the string it is passed to remain alive for the duration of the program's execution, so it is not freed after this call. */ Py_SetProgramName (progname_copy); ... Py_Initialize (); PyEval_InitThreads (); Upon reading the Python 3 C API documentation, I found (https://docs.python.org/3.5/c-api/memory.html): To avoid memory corruption, extension writers should never try to operate on Python objects with the functions exported by the C library: malloc(), calloc(), realloc() and free(). This will result in mixed calls between the C allocator and the Python memory manager with fatal consequences, because they implement different algorithms and operate on different heaps. However, one may safely allocate and release memory blocks with the C library allocator for individual purposes[...] And Py_SetProgramName seems like a very simple call that doesn't need a Python-allocated memory to work on. So I'm proposing this patch, which simply replaces PyMem_Malloc by xmalloc. Testing this is more complicated. First, the crash is completely non-deterministic; I was able to reproduce it 10 times in a row, and then I wasn't able to reproduce it anymore. I found that if you completely remove your build directory and rebuild GDB from scratch, you can reproduce it again confidently. And with my patch, I confirmed that the bug doesn't manifest even in this situation. No regressions found. OK to apply? gdb/ChangeLog: 2019-06-27 Sergio Durigan Junior PR python/24742 https://bugzilla.redhat.com/show_bug.cgi?id=1723564 * python/python.c (do_start_initialization): Use 'xmalloc' instead of 'PyMem_Malloc'. --- gdb/python/python.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/python/python.c b/gdb/python/python.c index 128bfc7588..2f5e94d86c 100644 --- a/gdb/python/python.c +++ b/gdb/python/python.c @@ -1602,7 +1602,7 @@ do_start_initialization () std::string oldloc = setlocale (LC_ALL, NULL); setlocale (LC_ALL, ""); progsize = strlen (progname.get ()); - progname_copy = (wchar_t *) PyMem_Malloc ((progsize + 1) * sizeof (wchar_t)); + progname_copy = (wchar_t *) xmalloc ((progsize + 1) * sizeof (wchar_t)); if (!progname_copy) { fprintf (stderr, "out of memory\n");