Re: [PATCH] git-svn: write memoized data explicitly to avoid Storable bug

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Jul 18, 2010 at 12:17, Sergey Vlasov <vsu@altlinux.ru> 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';
       }

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.