This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author enometh
Recipients enometh, shihai1991
Date 2021-08-22.12:26:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20210822.175704.2257033459608092404.enometh@meer.net>
In-reply-to <1629603770.32.0.682495978946.issue44913@roundup.psfhosted.org>
Content
*  hai shi <report@bugs.python.org> <682495978946.issue44913@roundup.psfhosted.org">1629603770.32.0.682495978946.issue44913@roundup.psfhosted.org>
Wrote on Sun, 22 Aug 2021 03:42:50 +0000

> hai shi <shihai1991@126.com> added the comment:

> How about this one?
>
>   if (!Py_IsInitialized()) {
>     return -1;
>   }

[When this extension is loaded into a C program rather than a python
script, then Python should be initialized here rather than quitting]

>   PyGILState_STATE state = PyGILState_Ensure();
>   PyObject *module_handle = PyModule_New(module_name);
>   if (module_handle == 0)
>   {
>     fprintf(stderr,"PyModule_New(module_data_name=%s) failed\n",
>             module_name);
>     exit(1);
>   }
>   fprintf(stdout, "point is: %p\n", module_handle);
>   fprintf(stderr, "foo END\n");
>   PyGILState_Release(state);

Yes. Thanks. Calling PyGILState_Ensure and PyGILState_Release around
the call to PyModule_New does avoid the segfault.

It is a little tricky to do this in pam-python - because although
there is one entrypoint into the extension (which can be wrapped
within the calls to PyGILState_Ensure/Release), python is initialized
within that entrypoint, but I think this can be solved another way.

Thanks
History
Date User Action Args
2021-08-22 12:26:49enomethsetrecipients: + enometh, shihai1991
2021-08-22 12:26:49enomethlinkissue44913 messages
2021-08-22 12:26:49enomethcreate