Thomas Unterthiner wrote: > When trying to hack together a small testcase I stumbled in some really > strange problems: removing object-files that have absolutely nothing to > do with the problem (e.g. the commandline-parsing code, which doesn't > even get executed anymore) made the Segfault go away. Linking the > program with that (dead) code included made it reapear. Other causes > that made the segfault go away was > commenting out sections of code (that again, have nothing to do with the > problem), removing variables from classes, ... So i'm still not able to > give a simple testcase. Those are always frustrating to debug. > At the beginning of main() esp has a value of 0x22ff7c - Independently > of wether the Segfault appears or not. However, those are the first > disassembled lines of the main-function (none of which have been > executed at the point where i looked at the value of esp): > > 0x40832a lea 0x4(%esp),%ecx > 0x40832e and $0xfffffff0,%esp > 0x408331 pushl 0xfffffffc(%ecx) > 0x408334 push %ebp > 0x408335 mov %esp,%ebp > > Wouldn't the line at 0x4832e align the value of %esp? Yes, that should align the stack. Clearly, my understanding of how this works is flawed. :) So, first, it should be easy enough to verify that we are in fact talking about a fault due to alignment -- check the value of the operands of the faulting SSE opcode. Then determine where the object gets allocated and how. If it's a global variable and it has a ctor then it is probably being constructed before main() when the list of global ctors is run. That could also explain why removing seemingly unrelated object files causes a change in behavior, since that would change the order of global ctors even if it's otherwise dead code. In this case you might play around with adding __attribute__((aligned(16))) to the declarations. Brian
