Python 3.6.1 support #69
Comments
|
I get the same error, Ubuntu 17.04, x64, trying to attach I just see From the ptrace manpage,
|
|
strace output indicates that it's all working nicely, looks like it follows a series of pointers before hitting a dead-end (expand details to see strace excerpt): |
|
Stack trace of pyflame (expand below). |
|
Success! Made it work. The problem was that configure was picking up To fix this I edited PKG_CHECK_MODULES([PY3], [python-3.6], [enable_py3="yes"], [AC_MSG_WARN([Building without Python 3 support])])Not sure of a good way of forcing this without editing the autoconf (e.g, via the It would be useful if there was a sanity check comparing the compiled-in-to-pyflame python version vs the one which is running. Thanks for a great tool :) |
|
Just to add to pwaller's post, this is caused by this PEP which changes the PyCodeObject. Maybe it is possible to support both >=3.6 and <3.6 by some dynamic check for this field, if the user has multiple Python 3 versions installed. Note that the PEP adds functionality that may or may not be interesting for this project, to quote:
|
|
I looked into this a little bit this evening. Here's what I found: On Debian/Ubuntu Pyflame is broken using Python 3.6 as described here. However, on my Fedora laptop (which is also running Python 3.6.1), Pyflame master works fine. So checking the Python version is not sufficient. The exact version of the package I have installed on Fedora is Currently the master test suite of Pyflame is failing, because somehow Travis changed and it's actually running Python 3.6 for the unit tests that are configured to run as Python 3.4 and Python 3.5, and thus tests are failing due to this bug. The fact that Travis is misconfigured is another issue I'm tracking at #76 It's possible that Fedora is applying a patch to Python 3 to undo PEP 523, but it doesn't seem likely. I haven't gone through the source RPM yet, but I see that my header files have the changes described in PEP 523, and my libpython has the new symbols: I am going to have to dig deeper to figure out what the root cause is. Here are two possibilities that I can think of right now. Scenario A: Fedora patches the Python source in some incredibly strange way that disables the new Python frame API, but for some reason kept the new symbols (and headers). Scenario B: this is somehow caused by the fact that Debian embeds the Python symbols, whereas Fedora dynamically links the symbols from libpython, and somehow that affects the code object/frame API. Both of these could be worked around, but both of them also seem very unlikely to me. I should have time to investigate further tomorrow. |
|
thanks for looking into this! i'd be happy to help! the pr i've got open definitely fixes it for my ubuntu 14.04 install, but yes 💯 don't want to break fedora. let me know what you turn up and i'd be happy to update my pr or be a guinea pig for changes |
|
It looks like #70 works with Fedora, so nothing needs to change there. However, there are some other minor changes that need to be made, which I have noted on the PR. This is looking pretty good though -- I think we're close to being able to merge the branch. |
|
It looks like the offset of @@ -15,21 +25,29 @@
int co_nlocals; /* #local variables */
int co_stacksize; /* #entries needed for evaluation stack */
int co_flags; /* CO_..., see below */
+ int co_firstlineno; /* first source line number */
PyObject *co_code; /* instruction opcodes */
PyObject *co_consts; /* list (constants used) */
PyObject *co_names; /* list of strings (names used) */
PyObject *co_varnames; /* tuple of strings (local variable names) */
PyObject *co_freevars; /* tuple of strings (free variable names) */
PyObject *co_cellvars; /* tuple of strings (cell variable names) */
- /* The rest doesn't count for hash or comparisons */
+ /* The rest aren't used in either hash or comparisons, except for co_name,
+ used in both. This is done to preserve the name and line number
+ for tracebacks and debuggers; otherwise, constant de-duplication
+ would collapse identical functions/lambdas defined on different lines.
+ */
unsigned char *co_cell2arg; /* Maps cell vars which are arguments. */
PyObject *co_filename; /* unicode (where it was loaded from) */
PyObject *co_name; /* unicode (name, for reference) */
- int co_firstlineno; /* first source line number */
PyObject *co_lnotab; /* string (encoding addr<->lineno mapping) See
Objects/lnotab_notes.txt for details. */This breaks things because now the @jmphilli Is going to update his diff to change the |
|
This change is landed! Thanks to @jmphilli for the hard work! To summarize the change:
When new Python versions are released, assuming they don't break the ABI, the process should be just updating the |
|
P.S. I tagged the release with this fix as 1.4.0, so that's the minimum version you need for the fix. |
I'm guessing that this applies to it being present in standard system locations. How can pyflame be made to work with Pythons installed with conda? |
|
w/ pyenv, for some reason, i had to |
|
For conda use similar approach |
|
I am hitting trouble with miniconda on Python 3.6.7 I am utilizing the approach darindf recommended for conda: (I am using the same conda environment to find the pkgconfig as the python program I am trying to trace), but I am getting For reference, i am trying to do this witha very minimal example: |
|
Bump! I'm having the same issue with miniconda. Followed the steps from @darindf but still get the |
Bleeding edge I know. Testing with Ubuntu 16.04 x64,
I only get
(idle) 2out of it. The same invocation works for python 3.5.2 and 2.7 on the same system. Attaching to a 3.6.1 process also only shows idle time. Sometimes, I instead getFailed to PTRACE_PEEKDATA at 0x10: Input/output errorwith different running processes, but I haven't figured out how to reproduce that.The text was updated successfully, but these errors were encountered: