Darin McBride <dmcbride@cpan.org> wrote: :This segfault is both consistent (as in, I have a non-trivial test case that :can expose it every time) and not (as in, if I make a small change, such as :introducing an extra class to my Moose hierarchy, the seg fault goes away). I can't answer the primary question; however, I did find a $work issue not so long ago which turned out to involve seemingly unrelated changes in a Moose hierarchy. It appears that Moose attributes in a class are in some way collected in a shared structure in the metaclass. When more attributes are defined in an unrelated class using the same metaclass, this can change the order the attributes are listed, and in particular change the order they get initialized during new(). (I didn't dig into the details, but I suspect they're stored in a hash, and that the order changes only when the number of hash keys grows to the point Perl decides to double the number of buckets.) In our case, this exposed "order of attribute initialization" dependencies of which we'd previously been unaware, in code that had been perceived as stable for several years. Maybe understanding how making "a small change, such as introducing an extra class" changes things such that the segfault goes away will help either to find a workaround, or to make a simpler test case to aid diagnosis. HugoThread Previous