2:29 p.m.
With current head of gcc-pyhton-plugin
(6b633d4d5159ddd1024ab5b66ff1feeb133184ed, plus slight modification
diff --git a/gcc-python-wrapper.c b/gcc-python-wrapper.c
index 93234b0..5f3ba56 100644
--- a/gcc-python-wrapper.c
+++ b/gcc-python-wrapper.c
@@ -28,7 +28,7 @@
#include "gcc-python-compat.h"
/* Debugging, for use by selftest routine */
-static int debug_gcc_python_wrapper = 0;
+static int debug_gcc_python_wrapper = 1;
/* Maintain a circular linked list of PyGccWrapper instances: */
static struct PyGccWrapper sentinel = {
@@ -142,6 +142,9 @@ my_walker(void *arg ATTRIBUTE_UNUSED)
printf("\n");
}
wrtp_mark = ((PyGccWrapperTypeObject*)Py_TYPE(iter))->wrtp_mark;
+ if (debug_gcc_python_wrapper) {
+ printf(" marking inner object; wrtp_mark = %p\n", wrtp_mark);
+ }
assert(wrtp_mark);
wrtp_mark(iter);
}
to see what's going on; btw, assert seems to not work for me there, even
with no NDEBUG in sight) and a trivial plugin script
import gcc
class UnusedArg(gcc.GimplePass):
def execute(self, fun):
pass
ps = UnusedArg(name='UnusedArg')
ps.register_after('lower')
at least one scenario of calling g++ (with large input, and -g; looks
like this is related to GCC having to trigger its GC) keeps crashing for
me with
[...]
gcc_python_wrapper_track: gcc.Function
gcc_python_wrapper_dealloc: gcc.Function
gcc_python_wrapper_untrack: gcc.Function
walking the live PyGccWrapper objects
marking inner object for: UnusedArg(name='UnusedArg')
marking inner object; wrtp_mark = (nil)
*** WARNING *** there are active plugins, do not report this as a bug unless you can
reproduce it without enabling any plugins.
Event | Plugins
PLUGIN_FINISH | python
[...]: internal compiler error: Segmentation fault
g++: internal compiler error: Aborted (program cc1plus)
at
#7 <signal handler called>
#8 0x0000000000000000 in ?? ()
#9 0x00007fc4aed5fc20 in my_walker (arg=<optimized out>) at
gcc-python-wrapper.c:149
#10 0x00000000006b59b1 in ggc_mark_root_tab (rt=0x7fc4aef74fe0) at
../../gcc/ggc-common.c:142
#11 ggc_mark_roots () at ../../gcc/ggc-common.c:164
#12 0x00000000005beed6 in ggc_collect () at ../../gcc/ggc-page.c:1934
#13 0x000000000072d0c5 in execute_todo (flags=3) at ../../gcc/passes.c:1293
#14 0x000000000072f28f in execute_one_pass (pass=0x10f8a80) at ../../gcc/passes.c:1579
#15 0x000000000072f5e5 in execute_pass_list (pass=0x10f8a80) at ../../gcc/passes.c:1611
#16 0x00000000007f1251 in tree_rest_of_compilation (fndecl=0x7fc4a356e400) at
../../gcc/tree-optimize.c:422
#17 0x0000000000916262 in cgraph_expand_function (node=0x7fc4a2cd9580) at
../../gcc/cgraphunit.c:1576
#18 0x00000000009182e4 in cgraph_output_in_order () at ../../gcc/cgraphunit.c:1733
#19 cgraph_optimize () at ../../gcc/cgraphunit.c:1894
#20 0x00000000009183f5 in cgraph_finalize_compilation_unit () at
../../gcc/cgraphunit.c:1096
#21 0x00000000005181c4 in cp_write_global_declarations () at ../../gcc/cp/decl2.c:4000
#22 0x00000000007bc1f2 in compile_file () at ../../gcc/toplev.c:591
#23 do_compile () at ../../gcc/toplev.c:1900
#24 toplev_main (argc=20, argv=0x7fff93e6ac18) at ../../gcc/toplev.c:1963
#25 0x00000037e682169d in __libc_start_main (main=0x4b0d00 <main>, argc=20,
ubp_av=0x7fff93e6ac18, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff93e6ac08) at libc-start.c:226
#26 0x00000000004bfad9 in _start ()
Stephan
6:55 p.m.
On Tue, 2012-01-17 at 21:29 +0100, Stephan Bergmann wrote:
With current head of gcc-pyhton-plugin
(6b633d4d5159ddd1024ab5b66ff1feeb133184ed, plus slight modification
> diff --git a/gcc-python-wrapper.c b/gcc-python-wrapper.c
> index 93234b0..5f3ba56 100644
> --- a/gcc-python-wrapper.c
> +++ b/gcc-python-wrapper.c
> @@ -28,7 +28,7 @@
> #include "gcc-python-compat.h"
>
> /* Debugging, for use by selftest routine */
> -static int debug_gcc_python_wrapper = 0;
> +static int debug_gcc_python_wrapper = 1;
>
> /* Maintain a circular linked list of PyGccWrapper instances: */
> static struct PyGccWrapper sentinel = {
> @@ -142,6 +142,9 @@ my_walker(void *arg ATTRIBUTE_UNUSED)
> printf("\n");
> }
> wrtp_mark = ((PyGccWrapperTypeObject*)Py_TYPE(iter))->wrtp_mark;
> + if (debug_gcc_python_wrapper) {
> + printf(" marking inner object; wrtp_mark = %p\n",
wrtp_mark);
> + }
> assert(wrtp_mark);
> wrtp_mark(iter);
> }
to see what's going on; btw, assert seems to not work for me there, even
with no NDEBUG in sight) and a trivial plugin script
> import gcc
>
> class UnusedArg(gcc.GimplePass):
> def execute(self, fun):
> pass
>
> ps = UnusedArg(name='UnusedArg')
> ps.register_after('lower')
at least one scenario of calling g++ (with large input, and -g; looks
like this is related to GCC having to trigger its GC) keeps crashing for
me with
> [...]
> gcc_python_wrapper_track: gcc.Function
> gcc_python_wrapper_dealloc: gcc.Function
> gcc_python_wrapper_untrack: gcc.Function
> walking the live PyGccWrapper objects
> marking inner object for: UnusedArg(name='UnusedArg')
> marking inner object; wrtp_mark = (nil)
> *** WARNING *** there are active plugins, do not report this as a bug unless you can
reproduce it without enabling any plugins.
> Event | Plugins
> PLUGIN_FINISH | python
> [...]: internal compiler error: Segmentation fault
> g++: internal compiler error: Aborted (program cc1plus)
Thanks for reporting this. I've converter the reproducer to a minimal
test case and attached it.
I think what's happening is that it's visiting an instance of a subclass
of a gcc.Pass, and that instance's PyTypeObject is simply a
PyTypeObject, not a PyGccTypeObject i.e. it doesn't have a wrtp_mark
hook, and the access of it is reading past the end of the PyTypeObject
(or to the insides of a PyHeapTypeObject)
So when Python creates PyTypeObjects for subclasses of a PyGccWrapper,
we need them to also be PyGccWrapperTypeObject, and to inherit the
wrtp_mark hook. I think that means setting the metaclass. I'm working
on a patch to do this.
Hope this is helpful
Dave
1:21 a.m.
On 01/18/2012 01:55 AM, David Malcolm wrote:
So when Python creates PyTypeObjects for subclasses of a
PyGccWrapper,
we need them to also be PyGccWrapperTypeObject, and to inherit the
wrtp_mark hook. I think that means setting the metaclass. I'm working
on a patch to do this.
Hope this is helpful
Thanks. FYI, I just bluntly added an if(wrtp_mark) in front of its use,
which appears to be a working stopgap.
Stephan
11:18 a.m.
On Wed, 2012-01-18 at 08:21 +0100, Stephan Bergmann wrote:
On 01/18/2012 01:55 AM, David Malcolm wrote:
> So when Python creates PyTypeObjects for subclasses of a PyGccWrapper,
> we need them to also be PyGccWrapperTypeObject, and to inherit the
> wrtp_mark hook. I think that means setting the metaclass. I'm working
> on a patch to do this.
>
> Hope this is helpful
Thanks. FYI, I just bluntly added an if(wrtp_mark) in front of its use,
which appears to be a working stopgap.
I've committed a fix (I hope) for this now, in git as:
eef8891a6efd628e9d5b9f47b7335be31b25c6e1 onwards. It looks like the
wrtp_mark callback was being read from an entirely wrong piece of memory
(see the commit message for the gory details!).
The fix is rather low-level and involves adding a metaclass, so please
let me know if the latest version in git works, and if you see any
unexpected behaviors (e.g. segfaults)
Thanks!
Dave
8:10 a.m.
On 01/18/2012 06:18 PM, David Malcolm wrote:
I've committed a fix (I hope) for this now, in git as:
eef8891a6efd628e9d5b9f47b7335be31b25c6e1 onwards. It looks like the
wrtp_mark callback was being read from an entirely wrong piece of memory
(see the commit message for the gory details!).
The fix is rather low-level and involves adding a metaclass, so please
let me know if the latest version in git works, and if you see any
unexpected behaviors (e.g. segfaults)
Fix works like a charm here.
Thanks,
Stephan
4489
days inactive
4491
days old
gcc-python-plugin@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
David Malcolm -
Stephan Bergmann