Replies: 9 comments 6 replies
-
|
Interesting! This normally happens when we are failing to copy some memory from the process so it normally means either some of the internal structures are changing as we sample or that we have a bug somewhere . Do you have a reproducer or a simple script we could run to try to get the error? Without that is a bit difficult to know why we're failing |
Beta Was this translation helpful? Give feedback.
-
|
I tried to narrow down what's going on. There's some randomness in it, but it seems that it happens when importing the "numba" package. I'll see if I can be more specific. But what's making it hard, is that when using pdb to debug the import process, sometimes it works! |
Beta Was this translation helpful? Give feedback.
-
|
Even more specifically, it seems to be the import of "llvmlite.binding". There's a bunch of other imports when you do that. It doesn't seem to be "llvmlite.ir", but again, there's a huge number of imports that happen and it's hard to figure out. I have numba 0.61.0 and llvmlite 0.44.0. I could try some other versions and see if anything changes. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, this is interesting. and then do |
Beta Was this translation helpful? Give feedback.
-
|
The lines which trigger the problem aren't in numba. They are in llvmlite.binding.executionengine: Comment them out and the tracing works. I don't know what it breaks. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, maybe what happens is that we are trying to read some python objects that we think we can read but they are altered by llvm? Without a reproducer or a stack trace is very difficult to know what are we failing to read :( |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this is what you are suggesting, re stack trace: Do I need to try and get more debugging symbols? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, that backtrace was junk. Wrong PID. This might be better: |
Beta Was this translation helpful? Give feedback.
-
|
Here's more with continuing: |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this is it! Looks like is this one: that tells us we are failing to check if the interpreter is shutting down and we are failing to read some weird memory address when copying from the interpreter address. This looks suspicious because it's pointing to a very odd address. That looks weird because it seems that we resolved _PyRuntime correctly so we should have the offsets correctly found. Maybe we failed somehow. I need to play a bit bit a reproducer will surely help |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how to pin this all down. I'm using a uv environment with python 3.13.7. I have llvmlite 0.44.0. I then just run python to get an interactive interpreter and do In another terminal I run pystack remote $(pidof -s python). I take it that's not enough information to reproduce? |
Beta Was this translation helpful? Give feedback.
-
|
I can give it a go, will get back to you :) |
Beta Was this translation helpful? Give feedback.
-
|
I think I got it I will be investigating what's going on |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Found the problem will work on a fix soon. See #255 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I frequently get the error: "Invalid address in remote process", but don't know what to do about it. With verbose logging, there isn't actually an error reported. Could the nature of the error be logged so that one can figure out what's going wrong?
Beta Was this translation helpful? Give feedback.
All reactions