Hide Forgot
Description of problem: glib.find_program_in_path crashes python for an invalid parameter. Version-Release number of selected component (if applicable): pygobject2-2.21.5-3.fc14.x86_64 How reproducible: always Steps to Reproduce: $ python Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import glib >>> glib.find_program_in_path("python") '/usr/bin/python' >>> glib.find_program_in_path("bla") python: /builddir/build/BUILD/Python-2.7/Objects/stringobject.c:124: PyString_FromString: Assertion `str != ((void *)0)' failed. Abgebrochen (Speicherabzug geschrieben) Actual results: python crashes with core dump Expected results: nice return value of glib.find_program_in_path Additional info: Please fix ASAP. I would like to suggest a patch for yumex for what I need this function working :)
This function got implemented with release version 2.21.0 18-dec-2009. https://bugzilla.gnome.org/show_bug.cgi?id=598435 See also http://git.gnome.org/browse/pygobject/tree/NEWS?id=7072d56b6cba13da97a052c75d1ae0c2cc417fd1
I would like to fix this yumex bug. https://bugzilla.redhat.com/show_bug.cgi?id=694752
According to the Glib Reference Manual: Returns an allocated string with the absolute path name, or NULL if the program is not found in the path. If program is already an absolute path, returns a copy of program if program exists and is executable, and NULL otherwise. Obviously, the return value NULL is mapped wrong into python.
I suggest None as the equivalent python value to NULL in C.
(In reply to comment #4) > I suggest None as the equivalent python value to NULL in C. The crash site is within /usr/src/debug/pygobject-2.27.0/glib/glibmodule.c: 588 static PyObject * 589 pyglib_find_program_in_path(PyObject *unused, PyObject *args, PyObject *kwargs) 590 { ... 599 600 ret = g_find_program_in_path(program); 601 retval = PYGLIB_PyUnicode_FromString(ret); ... 604 } PYGLIB_PyUnicode_FromString seems to be a macro on Python2 to PyString_FromString, which requires a non-NULL argument. It could be patched at this callsite, e.g. to use Py_RETURN_NONE (which increments the refcount of the None singleton), but PYGLIB_PyUnicode_FromString gets used in about 50-60 places throughout the package, so perhaps it's better to add the bullet-proofing there. Is the bug in pyglib_find_program_in_path being tracked upstream yet?
Hi Dave, thanks for your fast answer. PYGLIB_PyUnicode_FromString seems to be a macro on Python2 to PyString_FromString, which requires a non-NULL argument. Yes, I do understand the source as well in that matter, so I can go with and agree to your details and description. Also, I tried to implement a work-around, but did not succeed so far due to not having enough knowledge in the Python C API. From my side, there is no success to provide a working patch so far. I know that PyUnicode_FromString is used a lot in the source and therefore I wonder if other places are buggy too. According to the Python core code, there's no NULL value expected as the input parameter, so the caller would have to handle that special case. An alternative value would be to return an empty string (""), but None is the better choice, IMHO. Both would evaluate to the boolean value False for easy error checking with an if statement. > Is the bug in pyglib_find_program_in_path being tracked upstream yet? I read through the mailing lists a little bit. Unfortunately, I haven't found anything that this bug is reported clearly to upstream. More curious thing is that this bug exists also in other distributions and versions of pygobject2.
We managed to implement the xdg-open feature into yumex without a need for the find_program_in_path function. Therefore, Severity can be set to medium.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
http://git.gnome.org/browse/pygobject/commit/?id=379c1474a071292a1e8da413af2f5438cff09fc8