SIGSEV in datetime.timedelta (possibly from datetime's C delta_new)
#132413
Comments
What's the crash? please provide the traceback (shown on the terminal if possible) (not just the core dump). |
|
Sorry. Here is the python traceback. If you wanted a gdb or other traceback, let me know. |
If possible yes, so that we know where the crash exactly happens. If possible, you can use Also, it might be that |
IndexError when using ollama
|
Ah. It appears that it is an ollama issue after all. Ill raise it over there. |
|
@picnixz So, I just checked and it appears that ollama-python is pure python. (Ofc I realized this after I made the issue.) Would that bring the issue back here? They don't appear to be using CTypes, etc. |
|
That does look like it could be a CPython issue, though ollama has a few dependencies that include compiled code. I tried to reproduce it (3.13.1, MacOS, latest ollama) but I got Two useful ways forward could be:
|
Yes. The ollama package requires ollama to be installed and running a local server. |
|
Running python with the debug build I just compiled produces: |
|
On current 3.13 tip that line in datetime is cpython/Modules/_datetimemodule.c Line 2745 in 089c43f |
|
So, using GDB. I figured out that So, assuming that GDB is right on where cpython/Modules/_datetimemodule.c Lines 102 to 108 in 089c43f The other weird thing is that the assert on line 106 is not failing as it should (I have assertions turned on in my build) Since neither of those return paths in (I could be totally wrong on all this. :) |
|
Just realized that line numbers are different. Let me fix that |
|
Why |
|
@JelleZijlstra import httpx
client = httpx.Client(
# Any URL works
base_url="https://duckduckgo.com"
)
def req():
with client.stream("GET", "/") as r:
yield
# Cannot be inlined into the iter. If inlined, segfault does not occur
stream = req()
# Any iteration works. I just simplified it down to this.
next(iter(stream)) Also, I found the line where python crashes: https://github.com/encode/httpx/blob/9e8ab40369bd3ec2cc8bff37ab79bf5769c8b00f/httpx/_client.py#L158 |
|
Ok, so I think it's an issue with |
IndexError when using ollamadatetime.timedelta (possibly from datetime's C delta_new)
datetime.timedelta (possibly from datetime's C delta_new)|
Oh. Whoops. Didn't see that you changed the name |
datetime.timedelta (possibly from datetime's C delta_new)[/+]
datetime.timedelta (possibly from datetime's C delta_new)[/+]datetime.timedelta (possibly from datetime's C delta_new)
|
Has this been tested with _pydatetime to verify the issue is definitely in datetime.c? |
|
There seems to be a subtle issue as well: Python 3.14.0a7+ (heads/main:d4e2cdc15bd, Apr 12 2025, 10:58:46) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_datetime'] = None
>>> import httpx
...
... client = httpx.Client(
... # Any URL works
... base_url="https://duckduckgo.com"
... )
...
...
... def req():
... with client.stream("GET", "/") as r:
... yield
...
... # Cannot be inlined into the iter. If inlined, segfault does not occur
... stream = req()
...
... # Any iteration works. I just simplified it down to this.
... next(iter(stream))
...
>>>
>>> ^D
Exception ignored while closing generator <generator object req at 0x7f5fdcffd150>:
Traceback (most recent call last):
File "<python-input-3>", line 10, in req
File "/$HOME/lib/python/cpython/Lib/contextlib.py", line 162, in __exit__
File "/$HOME/Applications/python3.12/local/lib/python3.12/site-packages/httpx/_client.py", line 877, in stream
File "/$HOME/Applications/python3.12/local/lib/python3.12/site-packages/httpx/_models.py", line 971, in close
File "/$HOME/lib/python/cpython/Lib/contextlib.py", line 305, in helper
TypeError: 'NoneType' object is not callableNote that the exception being ignored while closing generator is only raised when exiting the interpreter, but the interpreter does not SIGSEV. Note that I'm using my 3.12 system-wide installation for the httpx package but other than that it shouldn't change anything. What's surprsing is that I cannot reproduce the crash itself with the latest main! I can reproduce the above issue however, but I cannot reproduce the SIGSEV. |
|
@Jacoblightning Can you try building the latest released version please? |
|
Still crashing for me on |
|
What os are you on? |
|
Oh btw, mine is openSUSE 15.5 and I was using gcc 7.5. So it could also be a GCC issue (or me not knowing how to check...) |
Arch linux |
|
I can check on my windows VM too but I can't do that until noon. |
|
@ZeroIntensity Since you're on AL, can you check if the error also persists on your side? TiA |
|
I can reproduce this using a fresh build off main, but I don't think this is an issue with My theory is that this has to do with reference counting problems on stackrefs + generator locals. |
|
@ZeroIntensity Can you also try with the Python implementation, if it also crashes then it would be a sideffect, otherwise datetime may be the culprit? I can test in a few hours on Linux. |
|
The crash doesn't occur with the Python implementation enabled, but Valgrind still explodes with errors. I'm pretty sure |
|
If cpython/Lib/importlib/_bootstrap.py Lines 1246 to 1248 in 281fc33 The same error can happen in the current cpython/Modules/_datetimemodule.c Lines 172 to 179 in 281fc33 Triggered by d82a7ba. I'll also check as much as I can. |
|
I've posted my questions, keeping aside the |
|
Generator's different behaviors are still surprising to me: def gen():
try:
print(1)
yield 2
finally:
print(3)
|
Uh oh!
There was an error while loading. Please reload this page.
Crash report
What happened?
I was testing some AI code with ollama and stumbled across a really weird crash.
The fact that it happens during an IndexError and a specific function has to be there leads me to believe that this is a CPython bug and not an ollama bug.
PythonCore.zip
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.13.2 (main, Feb 5 2025, 08:05:21) [GCC 14.2.1 20250128]
Linked PRs
The text was updated successfully, but these errors were encountered: