Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Sun, Jul 18, 2010 at 12:17, Sergey Vlasov <vsu@xxxxxxxxxxx> wrote: > > Apparently using the Storable module during global destruction is > > unsafe - there is a bug which can cause segmentation faults: > > > > http://rt.cpan.org/Public/Bug/Display.html?id=36087 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482355 > > I did some investigation into the upstream issue: > https://rt.cpan.org/Ticket/Display.html?id=36087#txn-806832 > > > The persistent memoization support introduced in commit 8bff7c538 > > relied on global destruction to write cached data, which was leading > > to segfaults in some Perl configurations. Calling Memoize::unmemoize > > in the END block forces the cache writeout to be performed earlier, > > thus avoiding the bug. > > Maybe I'm missing something obvious, but this seems like the wrong > solution. The core issue is that we don't want to clean up during > global destruction, but then we should just do: > > sub DESTROY { > return if not $memoized; > $memoized = 0; > > Memoize::unmemoize 'lookup_svn_merge'; > Memoize::unmemoize 'check_cherry_pick'; > Memoize::unmemoize 'has_no_changes'; > } I haven't looked at this issue in-depth, but I believe the problem is triggered due to Memoize::Storable trying to use Storable::nstore in its own DESTROY function. So trying to do the same in our own DESTROY would be just as bad. > That should work since memoize_svn_mergeinfo_functions(); is being > called in find_extra_svn_parents, which is a Git::SVN object > method. Can you try this and confirm/deny? I can't because I can't get > the original to segfault on my box when run within git-svn. I wasn't able to reproduce the segfault on my systems, either, but it seems plausible it would only happen on some systems. -- Eric Wong -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html