On 21.05.2012 17:55, Niall Douglas wrote: > 1. Does the bug occur in non-optimised as well as optimised builds? It does.
> 2. Does the bug occur when C++11 is turned off? It does not. > 3. What are your -fvisibility settings? Unchanged to default... Does this help any? Can I find out whats default on my machine if its configurable at gcc-build-time? > 4. Does the bug occur when inlining is force switched off? Yes. > 5. Are you using precompiled headers? If so, does the bug occur when > you turn those off? I think I am not. I would know if I did, wouldn't I? At least I can browse through the header sources at /usr/include/boost/.. > 6. Can you spot where in the assembly it's making a pointer > dereferencing mistake? That is in the template, but the pointer value changes inside code which is compiled in the boost library. Within the function defined around inheritance.cpp:392, the value of the object pointer (I think it's called p) changes. I was yet unable to find the specific point where the value is changed, because a lot of subfunctions get called in there and, to be honest, I'm not that familiar with gcc yet. Also it seems as maybe the wrong value is only passed, while it is still intact on stack (gcc at least shows me differing values for the two stackframes), but that might be due to debug data or gcc magic? > If you're *really* unlucky, the bug is that different assembler is > being generated in different compilands and the fact you're seeing a > problem is due to sheer chance because of the stochastic choice the > linker made :) Actually, the problem is deterministic. I compiled the binary many times now and with gcc 4.7 I always get the segfault, at the same instruction, with the same surroundings (changed pointer value from one stack frame to the other). -- Jonas _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
