Attached is a revised patch which addresses the valgrind errors.
Just to see how the new Python string solution works step-by-step, I
recreated it using some test structures and code in an interactive
Python shell. What I found was that the final string stored in a
test ctypes union (like pmAtomValue) would often be empty when the
original string was not. I'm not sure why the solution would work in
my PCP scripts and not in my test shell, but removing the cast to
c_char_p seems to have produced a solution that works for valgrind
and all situations I've thrown at it so far.
I still need to perform some large-scale tests of this revised
solution, but I'm hopeful it will work as expected.
On 4/14/14, 12:19 PM, Tom Yearke wrote:
Ow!
Glad you're doing better!
I've created a patch for the new solution that obtains the C
string address in a hopefully-safe, Python 2.5-friendly manner. It
will take a bit longer to test for the seg fault problem, but it's
passed the small scale tests I've done, so I wanted to get it out
ASAP for feedback.
I did notice some unusual valgrind messages for both the patched
and unpatched new solution, which did not occur for any of the
other solutions I've attempted. A series of errors like the
following are printed:
==14442== Invalid read of size 8
==14442== at 0x4A08BE8: memcpy (mc_replace_strmem.c:882)
==14442== by 0x458D26: PyString_FromString (stringobject.c:144)
==14442== by 0x44CFEA: PyObject_GenericGetAttr (object.c:1424)
==14442== by 0x49D216: PyEval_EvalFrameEx (ceval.c:2082)
==14442== by 0x4A00B7: PyEval_EvalFrameEx (ceval.c:3836)
==14442== by 0x4A00B7: PyEval_EvalFrameEx (ceval.c:3836)
==14442== by 0x4A119F: PyEval_EvalCodeEx (ceval.c:3000)
==14442== by 0x49F372: PyEval_EvalFrameEx (ceval.c:3846)
==14442== by 0x4A119F: PyEval_EvalCodeEx (ceval.c:3000)
==14442== by 0x4A1271: PyEval_EvalCode (ceval.c:541)
==14442== by 0x4C0D5D: PyRun_FileExFlags (pythonrun.c:1351)
==14442== by 0x4C0F73: PyRun_SimpleFileExFlags
(pythonrun.c:941)
==14442== Address 0x10ff1ca8 is 40 bytes inside a block of size
67 free'd
==14442== at 0x4A063F0: free (vg_replace_malloc.c:446)
==14442== by 0x4F6A21: frame_dealloc (frameobject.c:420)
==14442== by 0x4A00DD: PyEval_EvalFrameEx (ceval.c:3838)
==14442== by 0x4A119F: PyEval_EvalCodeEx (ceval.c:3000)
==14442== by 0x49F372: PyEval_EvalFrameEx (ceval.c:3846)
==14442== by 0x4A119F: PyEval_EvalCodeEx (ceval.c:3000)
==14442== by 0x4A1271: PyEval_EvalCode (ceval.c:541)
==14442== by 0x4C0D5D: PyRun_FileExFlags (pythonrun.c:1351)
==14442== by 0x4C0F73: PyRun_SimpleFileExFlags
(pythonrun.c:941)
==14442== by 0x413EB7: Py_Main (main.c:577)
==14442== by 0x3F7821ED1C: (below main) (in
/lib64/libc-2.12.so)
It doesn't seem to occur for every string fetch, and the new code
doesn't appear to impact the contents of the returned strings, but
I thought it might be important to share.
On 4/14/14, 10:35 AM, Stan Cox wrote:
I believe Stan has strained his back
Torn oblique; but I am running on all cylinders now (finally!).
I will poke at this today, which is EDT for me.
_______________________________________________
pcp mailing list
pcp@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/pcp
|
patch.diff
Description: Text document
|