Carl Witty wrote:
> Are you sure that the problem is with the call to _copy? I'd think
> that an aliasing problem would be at least as likely (probably more
> likely) to show up in the initialization; so maybe your _XSLTContext
> object doesn't actually have the right vtable, or maybe the "_copy"
> entry in the vtable somehow points to the wrong function.
You're right, the vtable is set up incorrectly:
-------------------------------
(gdb) print __pyx_vtable_4lxml_5etree__XSLTContext
$5 = {__pyx_base = {_copy = 0xb7c7cb50
<__pyx_f_4lxml_5etree_12_BaseContext__copy>, _to_utf = 0xb7cc8510
<__pyx_f_4lxml_5etree_12_BaseContext__to_utf>,
[...]
_hold = 0xb7c32500 <__pyx_f_4lxml_5etree_12_BaseContext__hold>},
register_context = 0xb7c6af70
<__pyx_f_4lxml_5etree_12_XSLTContext_register_context>, free_context =
0xb7c360f0 <__pyx_f_4lxml_5etree_12_XSLTContext_free_context>}
-------------------------------
So, it looks like "__pyx_base" is somehow broken here. When I compile with
"-fno-strict-aliasing", I get this:
-------------------------------
(gdb) print __pyx_vtable_4lxml_5etree__XSLTContext
$1 = {__pyx_base = {_copy = 0xb7b163f0
<__pyx_f_4lxml_5etree_12_XSLTContext__copy>, _to_utf = 0xb7bbdc20
<__pyx_f_4lxml_5etree_12_BaseContext__to_utf>,
[...]
_hold = 0xb7b24c60 <__pyx_f_4lxml_5etree_12_BaseContext__hold>},
register_context = 0xb7b5e590
<__pyx_f_4lxml_5etree_12_XSLTContext_register_context>, free_context =
0xb7b28910 <__pyx_f_4lxml_5etree_12_XSLTContext_free_context>}
-------------------------------
Also, when I compile with gcc 4.2 instead of 4.3, it just works. Stepping
through the module init function, I noticed that gcc generates the
assignment code in the wrong order. The second of the two statements
-------------------------------
__pyx_vtable_4lxml_5etree__XSLTContext.__pyx_base =
*__pyx_vtabptr_4lxml_5etree__BaseContext;
*(void(**)(void))&__pyx_vtable_4lxml_5etree__XSLTContext.__pyx_base._copy
= (void(*)(void))__pyx_f_4lxml_5etree_12_XSLTContext__copy;
-------------------------------
ends up being executed before the first one, so that the first assignment
overwrites the value of _copy(). Great. I also noticed that this only
happens when I optimise with "-march=core2", while the "prescott"
architecture works. Looks like a gcc bug to me.
Thanks for the help.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
