terminated by signal SIGSEGV (Address boundary error)

[varadpatil]

I'm using psycopg3 pool. I fetch data from database using the following code.

@staticmethod
async def sql(pool, sql):
    async with pool.connection() as aconn:
        async with aconn.cursor() as acur:
            await acur.execute(sql)
            return await acur.fetchall()

Current thread 0x0000711be45ff000 (most recent call first):
  File "/home/varad/CWD/algo_trading/dev/tiger/theta_decay2/.venv/lib/python3.10/site-packages/psycopg/types/datetime.py", line 542 in _load_iso
  File "/home/varad/CWD/algo_trading/dev/tiger/theta_decay2/.venv/lib/python3.10/site-packages/psycopg/types/datetime.py", line 507 in load
  File "/home/varad/CWD/algo_trading/dev/tiger/theta_decay2/.venv/lib/python3.10/site-packages/psycopg/_transform.py", line 309 in load_rows
  File "/home/varad/CWD/algo_trading/dev/tiger/theta_decay2/.venv/lib/python3.10/site-packages/psycopg/cursor_async.py", line 195 in fetchall
  File "/home/varad/CWD/algo_trading/dev/tiger/theta_decay2/algo/rm2.py", line 162 in sql

There is no way I can catch this in python itself (or atleast I don't know any way to catch it in python itself). Have anyone faced similar thing?

Here is my verion of psycopg.

psycopg 3.1.19 PostgreSQL database adapter for Python
├── psycopg-pool *
│   └── typing-extensions >=4.4 
├── typing-extensions >=4.1
└── tzdata *

Till the time it is closed, is there any other version that is known to not have this issue?

[dvarrazzo]

The line failing is https://github.com/psycopg/psycopg/blob/ef8d6a307244521ed7ea528fc1c1929e43a3b68a/psycopg/psycopg/types/datetime.py#L542 What value triggers the error?

[varadpatil]

There is no specific value, and the same value doesn't always produce error. I run my app again and it may not fail. The behaviour is not regular.

[dvarrazzo]

As you can see, the line where you have a sigsegv is just a Python statement. What platform are you using? Are you customize the timezone objects in any way?

[varadpatil]

I'm on Ubuntu Linux.

The query I am executing is simply a SELECT query, with some filters and ORDER BY. The result it is supposed to return has some columns that have timestamp data, but there is no timezone customization. Here is the datatype taken from information_schema.columns for those columns.

        data_type         
--------------------------
 timestamp with time zone
(1 row)

[dvarrazzo]

This issue is really strange: the line where it happens is: ``` (dt - tzoff).astimezone(self._timezone) ``` which is a normal Python statement. So this seems at most a bug in Python to me. The entire psycopg development happened on Ubuntu and I've never stumbled in that error. Also, curious thing is that you get a Python traceback at all: usually the way cpython crashes in C is to just die and leave a core file if the OS is configured so, not to print a Python traceback. So, I think you have something on your computer that causes that problem, which is a Python problem, not a psycopg one. If you want to do something to help us looking at what happens please instrument psycopg to print to a file the value of the variables before and after the statement in question. If we don't have anything reproducible, or at least the value in which the episode happens, we cannot do anything to avoid it.

[varadpatil]

You are right @dvarrazzo python doesn't give any traceback and just dies. Since I was not able to catch any exception at python level and my program was just dying, I added following lines to my code.

import faulthandler

faulthandler.enable()

This is what is giving the error traceback. Without this It just dies. The fact that there is no python exception that I could catch hints towards something with lower level C.

Also the same value sometimes gives this issue, and sometimes doesn't is hinting towards concurrency issue (or something of that sort). I'm using async connection pool.

This is troubling me, please let me know if any additional information is required. I would request to consider this for fixing.

[akrherz]

I am likely making unhelpful noise here, but when I have seen this type of issue within apps that use "fancy" threading, I add an arbitrary and very early exercise of the offending python API, so that the c module is called before any threading stuff gets loaded. For example if you are using zoneinfo, at the program front end and the first thing it does. This sometimes makes the problem "go-away" and offers a temporary band-aid.

from zoneinfo import ZoneInfo
ZoneInfo("UTC")
import os
import sys ... etc

[dvarrazzo]

Thank you Daryl, this is useful indeed. To the OP: as far as I see, this is a Python bug, between zoneinfo and threading, and it should be reported to python devs. I don't have a repro of "fancy threading" to propose as repro upstream, so I will leave that to you.

This is troubling me, please let me know if any additional information is

required. I would request to consider this for fixing. This is no psycopg bug and will be closed as soon as I have web access to GitHub, in a couple of days. If you want us to fix it I would request you to consider sponsoring the work.

[dvarrazzo]

This is a segfault on a Python statement, so it is a Python bug.

It's an issue I have never found in development, which happened on Ubuntu too. I can only work on it if a proper way to reproduce the issue is provided.

[varadpatil]

Thanks @akrherz, your unhelpful noise was rather very helpful. I'm no longer getting SIGSEGV. Also thanks @dvarrazzo for looking into it and pointing out that it's comming from Python.