From: Eric Wong Date: Tue, 20 Jul 2010 19:02:23 GMT Subject: Re: [PATCH] git-svn: write memoized data explicitly to avoid Storable bug Message-ID: <20100720190223.GB2732@dcvr.yhbt.net> In-Reply-To: Ævar Arnfjörð Bjarmason wrote: > On Sun, Jul 18, 2010 at 12:17, Sergey Vlasov 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