Bug 1723564
Summary: | gdb crash when using PYTHONMALLOC=debug on Python | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Victor Stinner <vstinner> |
Component: | gdb | Assignee: | Sergio Durigan Junior <sergiodj> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 30 | CC: | dsmith, jan.kratochvil, keiths, kevinb, pmuldoon, sergiodj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | gdb-8.3-6.fc30 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-07-05 01:32:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Victor Stinner
2019-06-24 20:06:36 UTC
Thanks for the report, Victor. I was able to reproduce this with upstream GDB as well, so I'll forward this bug to upstream. However, something interesting happened: on my F30, I was only able to reproduce this bug once. When I tried again, GDB would start normally. I wonder why this is happening here... I was also able to reproduce this on a Rawhide VM, using upstream GDB. This seems like a very specific use case. Would you recommend unsetting these two environment variables before we start initializing Python? Thanks. > I was able to reproduce this with upstream GDB as well, so I'll forward this bug to upstream. However, something interesting happened: on my F30, I was only able to reproduce this bug once. When I tried again, GDB would start normally. I wonder why this is happening here... Memory allocations are not really deterministic. ASLR might enter into the play. File modification time as well. Many things can change the exact memory allocation order. free() does not always crash when misused :-) > This seems like a very specific use case. Would you recommend unsetting these two environment variables before we start initializing Python? Well, there are multiple options: * investigate how Python memory allocator functions are used * Use PEP 587 on Python 3.8 and newer (that doesn't fix the issue for Python 3.7 and older) * Unset PYTHONMALLOC and PYTHONDEVMODE env var, or unset all PYTHON* vars (what about PYTHONPATH for example? it's up to you) I'm using PYTHONMALLOC and PYTHONDEVMODE to debug Python applications. I didn't *expect* that gdb would use them :-) (In reply to Victor Stinner from comment #2) > > I was able to reproduce this with upstream GDB as well, so I'll forward this bug to upstream. However, something interesting happened: on my F30, I was only able to reproduce this bug once. When I tried again, GDB would start normally. I wonder why this is happening here... > > Memory allocations are not really deterministic. ASLR might enter into the > play. File modification time as well. Many things can change the exact > memory allocation order. free() does not always crash when misused :-) I understand that, but what surprised me was that I was able to reproduce the bug like 10 times in a row, and then wasn't able to reproduce it anymore after hundreds of times. > > This seems like a very specific use case. Would you recommend unsetting these two environment variables before we start initializing Python? > > Well, there are multiple options: > > * investigate how Python memory allocator functions are used > * Use PEP 587 on Python 3.8 and newer (that doesn't fix the issue for Python > 3.7 and older) > * Unset PYTHONMALLOC and PYTHONDEVMODE env var, or unset all PYTHON* vars > (what about PYTHONPATH for example? it's up to you) I think there may be a simpler solution. I have a patch here, but as I said, I can't reproduce the bug anymore. > I'm using PYTHONMALLOC and PYTHONDEVMODE to debug Python applications. I > didn't *expect* that gdb would use them :-) GDB doesn't use them, as far as I know and have researched. (In reply to Sergio Durigan Junior from comment #3) > I think there may be a simpler solution. I have a patch here, but as I > said, I can't reproduce the bug anymore. I managed to reproduce the bug here (by removing everything from the build directory and rebuilding GDB), and managed to test the patch. It seems to work. I will propose it upstream, let's see what they say. Patch has been pushed upstream: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5af5392a3d1525fb825747b203a6159ddcba0aa4 I'll backport it to F30. FEDORA-2019-0497420860 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0497420860 gdb-8.3-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0497420860 FEDORA-2019-4a8ba02caf has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4a8ba02caf gdb-8.3-6.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4a8ba02caf gdb-8.3-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. I tested manually gdb-8.3-6.fc30 and I confirm that gdb no longer crash for my use case, thanks! |