Windows access violation with Instant.from_utc()

[ArneBachmannDLR]

Trying to call Instant twice in a row hard-crashes the interpreter. I created a fresh conda environment and got this result:

(adb) D:\forks\IT\assetdb>python
Python 3.11.9 | packaged by conda-forge | (main, Apr 19 2024, 18:27:10) [MSC v.1938 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

>>> from whenever import Instant
>>> Instant.from_utc(1970, 1, 1)
Instant(1970-01-01 00:00:00Z)
>>> Instant.from_utc(1970, 1, 1)
Windows fatal exception: access violation

Current thread 0x0000527c (most recent call first):
  File "<stdin>", line 1 in <module>

I was initially assuming that my date computation was before 1.1.1970 leading to a negative unix timestamp + crash, but in this case there must be something else.

[ariebovenberg]

Thanks for posting! Looks like it's something else indeed. I'll have a look

[ariebovenberg]

It shouldn't have anything to do with the system time settings BTW, from_utc is just a simple object instantiation. Looks like the problem may be incorrect object deallocation, which can be tricky to reproduce.

In any case I wasn't so lucky to be able to reproduce, even on a matching conda/python/windows environment:

 PS C:\Users\acbov> python
Python 3.11.9 | packaged by Anaconda, Inc. | (main, Apr 19 2024, 16:40:41) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from whenever import Instant
>>> Instant.from_utc(1970, 1, 1)
Instant(1970-01-01 00:00:00Z)
>>> Instant.from_utc(1970, 1, 1)

Do you get the same problem with other values (e.g. Instant.from_utc(1980, 1, 1))? Or other classes (e.g. Time(0))?

[ArneBachmannDLR]

So weird...

>>> from whenever import Time
>>> Time(0)
Time(00:00:00)
>>> Time(0)
Windows fatal exception: access violation

>>> Instant.from_utc(1980,2,3)
Instant(1980-02-03 00:00:00Z)
>>> Instant.from_utc(1980,2,4)
Windows fatal exception: access violation

[ariebovenberg]

Hmmm. What if you do:

>>> Time(0)  # don't assign this to a variable!
>>> object()  # clears the reference to the previous object

That at least narrows the problem down to deallocation

[ArneBachmannDLR]

>>> Time(0)
Time(00:00:00)
>>> object()
Windows fatal exception: access violation

[ariebovenberg]

Alright, the issue is at least pinpointed. It appears on some windows installation, the deallocation routine fails. This is a bit surprising, since it's basically copied from established examples.

The real tricky bit is debugging if I can't reproduce...

One sanity check you could do: does using any other rust extension work? Can you try fastuuid?

>>> fastuuid.uuid4()
>>> object()

[ariebovenberg]

Ok I have an idea. Can you try my attempt at a fix (pip install whenever==0.6.8rc1)? It should be out once this workflow completes

[ArneBachmannDLR]

Seems to work!

>>> fastuuid.uuid4()
UUID('a66b265a-8901-4e8c-a72e-9ec0a08a66bd')
>>> object()
<object object at 0x000001FE46156920>

... upgrade whenever...
>>> from whenever import Time
>>> Time(0)
Time(00:00:00)
>>> Time(0)
Time(00:00:00)
>>> Time(0)
Time(00:00:00)
>>> from whenever import Instant
>>> Instant.from_utc(1970,1,1)
Instant(1970-01-01 00:00:00Z)
>>> Instant.from_utc(1970,1,1)
Instant(1970-01-01 00:00:00Z)

[ariebovenberg]

Excellent. A proper release (0.6.8) should be out once this workflow finishes.

[ArneBachmannDLR]

That's amazing! Was already able to continue the refactoring to the latest version which doesn't use _AwareDateTime anymore and replaced it with Instant

[ariebovenberg]

Happy to hear it. Thanks for taking the time to post 👍