Vincent Vande Vyvre schrieb am 13.10.2017 um 13:18:
> Le 13/10/17 à 12:39, Paul Moore a écrit :
>> As a specific suggestion, I assume the name of the created file is a
>> string object constructed in the C extension code, somehow. The fact
>> that you're getting the segfault with some uses of that string
>> (specifically, passing it to %-formatting) suggests that there's a bug
>> in the C code that constructs that string. That's where I'd start by
>> looking.
Absolutely.
> That was my first idea, because I can verify the instance of PyUnraw is not
> destroyed when I use the file name, but I was in trouble by the usage of
> the file name in string formatting.
>
> For example I can use the file name into the slot i.e. shutil.copy(fname,
> "path/renamed.tiff")
> The file is correctly copied.
>
> In fact, I can do anything with the file name except use it in string
> formatting, then your approach is probably a good way.
>
> Into the CPython part I have a c-string pythonized by:
> temp = self->outfname;
> self->outfname = PyUnicode_FromString(ofname);
> Py_XDECREF(temp);
>
> and exposed to Python with:
> static PyMemberDef PyUnraw_members[] = {
> {"out_file", T_OBJECT_EX, offsetof(PyUnraw, outfname), 0,
> "Path of the decoded file"},
One more suggestion, in case this is actually your own C code: it's much
easier to write extension modules in Cython than in plain C and C-API code.
Much easier. There is a learning curve, sure, but it unburdens you from so
many pitfalls and boilerplate code that it's always worth switching. And
you also get faster code as a side-effect. How's that for a tradeoff. :)
Stefan
(Cython core developer)
--
https://mail.python.org/mailman/listinfo/python-list
