Before this change, Interp::_setup would be destroyed after the program exited,
which is generally after Py_Finalize is called. But the (synthesized)
destructor of Interp::setup would call the destructor of a boost::python::
object pythis, leading to Python API calls including to subtype_dealloc, which
causes routine crashes when axis exits on Python 2.7.5-4 (Debian Unstable)
With this change, by the use of references and memory allocated with operator
new, the destructor is never called for _setup; we just leak the memory
instead.
---
This is on a debian unstable machine, Python version is 2.7.5-4.
The best information I've been able to get is from valgrind, which says:
==8164== Invalid read of size 4
==8164== at 0x533F9B: subtype_dealloc.25582 (typeobject.c:955)
==8164== by 0xE165345: setup_struct::~setup_struct() (interp_internal.hh:570)
==8164== by 0x59A5AA0: __run_exit_handlers (exit.c:77)
==8164== by 0x59A5B24: exit (exit.c:99)
==8164== by 0x598D99B: (below main) (libc-start.c:294)
==8164== Address 0x98 is not stack'd, malloc'd or (recently) free'd
I *believe* that the scenario is:
* at this point, Py_Finalize has been called, so no further Python API calls
may take place
* the synthesized method setup_struct::~setup_struct() releases
boost::python::object pythis
* this makes Python calls leading to subtype_dealloc, because this was the
last reference
to the object -- now you've violated an invariant required by Python
This feels like a band-aid fix for the real problem, but it's the best I have.
Since I feel this is a bandaid fix I'm not pushing, in case Michael has a
better fix he can bring to bear.
I encountered this at the tip of ja3 but assume it affects master as well.
src/emc/rs274ngc/interp_array.cc | 2 +-
src/emc/rs274ngc/rs274ngc_interp.hh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/emc/rs274ngc/interp_array.cc b/src/emc/rs274ngc/interp_array.cc
index 19880fd..d4d113a 100644
--- a/src/emc/rs274ngc/interp_array.cc
+++ b/src/emc/rs274ngc/interp_array.cc
@@ -311,7 +311,7 @@ const read_function_pointer Interp::default_readers[256] = {
/* There are four global variables*. The first three are _gees, _ems,
and _readers. The last one, declared here, is for interpreter settings */
-setup Interp::_setup;
+setup &Interp::_setup = *new setup;
/* The notion of "global variables" is a misnomer - These last four should only
be accessable by the interpreter and not exported to the rest of emc */
diff --git a/src/emc/rs274ngc/rs274ngc_interp.hh
b/src/emc/rs274ngc/rs274ngc_interp.hh
index 9e28b13..6bf0397 100644
--- a/src/emc/rs274ngc/rs274ngc_interp.hh
+++ b/src/emc/rs274ngc/rs274ngc_interp.hh
@@ -625,7 +625,7 @@ int read_inputs(setup_pointer settings);
read_function_pointer _readers[256];
static const read_function_pointer default_readers[256];
- static setup _setup;
+ static setup &_setup;
enum {
AXIS_MASK_X = 1, AXIS_MASK_Y = 2, AXIS_MASK_Z = 4,
--
1.8.4.rc3
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
