[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Seg fault, Perl bindings, "perl -c"

From: Nik Clayton <nik_at_ngo.org.uk>
Date: 2006-09-12 13:00:05 CEST

Malcolm Rowe wrote:
> On Tue, Sep 12, 2006 at 10:56:11AM +0100, Nik Clayton wrote:
>> If you use Perl's "-c" command line option to check the syntax of a Perl
>> program that uses SVN::Core you get a seg fault.
>> % perl -c -MSVN::Core -e 'print "hello, world\n";'
>> -e syntax OK
>> Segmentation fault (core dumped)
> In the SVN::Web source, you noted that this might be "Something to do
> with the interaction between "-c" running BEGIN blocks but not running
> END blocks, or similar." Do you still think that's part of the problem?

Yes, but that's based on nothing more than a hunch, and the following in
the Perl docs:

  -c causes Perl to check the syntax of the program and then exit with-
       out executing it. Actually, it will execute "BEGIN", "CHECK", and
       "use" blocks, because these are considered as occurring outside
       the execution of your program. "INIT" and "END" blocks, however,
       will be skipped.

Mathias' reply said he got this error:

   Use of uninitialized value in string eq at
   /usr/lib/perl5/site_perl/5.8/cygwin/SVN/Core.pm line 410 during global

That's here, in SVN/Core.pm:

     return if $globaldestroy;
     my $self = shift;
     if ($$self eq $SVN::_Core::current_pool) { # line 410
         $SVN::_Core::current_pool = pop @POOLSTACK;
     if (exists $WRAPPOOL{$self}) {
         delete $WRAPPOOL{$self};
     else {
         apr_pool_destroy ($$self)

This is in the SVN::Pool package in that file. That this is being
called suggests that somewhere in the initialisation path an SVN::Pool
object is being created.


<fx: smacks forehead>

The first chunk of code in SVN::Core.pm looks like this:


our $gpool = SVN::Pool->new_default;


That line "our $gpool = SVN::Pool->new_default;" is going to be executed
when SVN::Core is 'used' (either with 'use SVN::Core;' or the -M command
line option. Which creates an SVN::Pool object. Which is then cleaned
up, and the DESTROY method fires, which tries to use something that's
already been cleaned up.

A quick fix, which passes the test case I've provided is to change this
line in Core.pm:

     our $gpool = SVN::Pool->new_default;

to this:

     our $gpool = SVN::Core::pool_create(undef);

That needs reviewing by someone who's got a greater understanding of the
pool API than I do, however.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 13:00:43 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.