-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't crash in SQL_ASCII DBs in PyString_AsString #43
Conversation
I thnk it looks great and very much welcome shaheed doing the needful
…On Sat, May 11, 2024 at 2:52 AM ShaheedHaque ***@***.***> wrote:
I've not tested this, but am happy to merge in a few days unless vetoed by
@luss <https://github.com/luss>.
Question: let's say your efforts under #44
<#44> were merged. What
would a new test based on the notes above look like?
—
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHSOM63LWFCBDNQESH3ZBW52ZAVCNFSM6AAAAABHP2DMW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGYYDANRXGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@@ -169,7 +169,7 @@ char * | |||
PyString_AsString(PyObject *unicode) | |||
{ | |||
char *rv; | |||
PyObject *o = PyUnicode_AsEncodedString(unicode, GetDatabaseEncodingName(), NULL); | |||
PyObject *o = PyUnicode_AsEncodedString(unicode, getPythonEncodingName(), NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realise that getPythonEncodingName()
predates this commit, and my C is VERY rusty, but technically, is that function not buggy in returning the address of a local (i.e. temporary)? IMHO, since this commit will greatly increase the use of that function, it would be nice to move the string "ascii" to file scope, and return it's address to prevent an over-eager compiler messing things up. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with your assessment. I've moved the constant to a file scoped static and retested it.
In #46 I've had to code the test DB to run under "UTF8" in order to avoid this bug -- Line 143 in b50d02d
I'll likely remove that in #46 after merging this. Based upon the positive reviews and having addressed the C local comment, I'm going to make use of @luss's newly granted merge rights to go ahead with this. Thanks! |
When a PostgreSQL database is running in SQL_ASCII encoding, anything in multicorn that touches PyString_AsString or PyString_AsStringAndSize will encounter an encoding error because "SQL_ASCII" isn't a valid Python encoding; and then the
errorCheck()
function will attempt to get the error that occurred, callreportException
, which callsPyString_AsString
, resulting in infinite recursion until the process segfaults.It seems that there's already a workaround in the form of the
getPythonEncodingName
name which translates SQL_ASCII to "ascii", used in some functions, but not in these ones; so I've applied those here.Reproduction steps:
initdb -E SQL_ASCII
Behavior before this patch: segfault; when debugged this codepath can be found (for the schema import scenario, if I remember correctly):
Behavior after: both an import and a delete works without segfault, at least.