-
-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document Tips for Debugging C Extensions #35100
Conversation
setup.py
Outdated
@@ -435,8 +433,14 @@ def run(self): | |||
else: | |||
extra_compile_args = ["-Werror"] | |||
extra_link_args = [] | |||
if debugging_symbols_requested: | |||
extra_compile_args.append("-g") | |||
if not debugging_symbols_requested: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess Python by default (at least locally and looking at some of the CI builds) includes the -g
flag as part of the CFLAGS that distutils uses to compile extensions, so in the current setup this does nothing.
According to SO we can override that by appending here, which might help reduce file size by removing those symbols:
https://stackoverflow.com/a/37952343/621736
I can also remove this from this PR if deemed too orthogonal. IIRC @xhochy or @TomAugspurger may have experience with stripping debug symbols from built distributions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multibuild may do this by default now? I don't recall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, multibuild includes this nowadays.
setup.py
Outdated
# Strip debugging symbols (included by default) | ||
extra_compile_args.append("-g0") | ||
else: | ||
# TODO: these should override the defaults provided by Python |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
distutils adds NDEBUG and -O3 by default it seems without a feasible way to remove those compilation flags. Appending these at the end should override those according to the SO link shared above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't recommend building with -O0
actually as it hides a lot of problems. In case of -O0
memory is mored often zeroed and thus invalid memory access is not that fatal (in the higher -Ox
cases you would get random data). This makes the detection of bugs a lot harder. It might be better to keep the optimization level here and add flags that make debugging easier. Personally I like -ggdb -fno-omit-frame-pointer
. This gives better stacktraces and a bit more debugging information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gdb suggests turning off optimizations:
https://sourceware.org/gdb/onlinedocs/gdb/Optimized-Code.html
There are certainly exceptions but I think as a general rule (especially for people that aren't super well versed in debugging the extensions yet) that no optimizations will be easier to follow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the debug information with -O0
is definitely better, I would like to leave -fno-omit-frame-pointer
somewhere here in the document as this is the option that provides the most debug information for the smallest performance hit and is really useful if you have an memory-out-of-bounds issue that wouldn't occur easily in the unoptimized version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I think this is off by default with -O0 per the docs but doesn't hurt to add again
https://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html
|
||
.. code-block:: sh | ||
|
||
gdb --args python -m pytest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ gdb --args python3 -m pytest
[...]
"~/.pyenv/shims/python3": not in executable format: File format not recognized
(gdb) run
Starting program: -m pytest
No executable file specified.
Use the "file" or "exec-file" command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try gdb -ex r --args python3 -m pytest
? Taking that from this link:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea looks like gdb -ex r --args python3 -m pytest pandas/tests
was working for me if you want to try on yours and confirm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ gdb -ex r --args python3 -m pytest pandas/tests
[...]
"~/.pyenv/shims/python3": not in executable format: File format not recognized
Starting program: -m pytest pandas/tests
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you using pyenv for development or Conda?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you've already gone above and beyond helping me debug this; ill spend some more time on this and ping you if i find anything new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good - I think this is generally helpful to hash out together so thanks for the input.
It looks like this might be specific to pyenv and how it manages the python executable:
https://stackoverflow.com/questions/48141135/cannot-start-dbg-on-my-python-c-extension
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gdb -ex r --args bash pytest pandas/tests --skip-slow --skip-db
tentatively looks like a winner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the command from my previous comment specific to my case, or relevant to the document?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to avoid adding too much detail here since this issue is more of a pyenv thing than a debugger issue
Any other comments here? Otherwise plan on merging in a few days |
One question, no objections. |
Using a debugger | ||
================ | ||
|
||
You can create a script that hits the extension module you are looking to debug and place it in the project root. Thereafter launch a Python process under lldb: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a reference on lldb (link / how to install?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have only used on macOS where it comes bundled with the Xcode tools. Not sure about other systems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On my ubuntu machine it's not available (while gdb
is). So I would at least link to some web page about it if we want to recommend it over gdb, I suppose most readers won't know what lldb is (I also didn't).
it seems you can install it from conda-forge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear I don't recommend one over the other - should just use whatever comes with your build system.
I'll try to reword
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you settle on a wording here?
any movement here? |
Been tight on time lately so closing this temporarily to clean the queue - will come back to this at a later date |
Getting back around to this. Since there was some confusion around gdb vs lldb I added a blurb about which one to choose when. I also made it so all of the steps are shown for both debuggers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
thanks @WillAyd |
Co-authored-by: William Ayd <will_ayd@innobi.io>
Quick notes in case they are helpful to others. Can move to the Wiki as well if we don't want in the standard docs