http://qs1969.pair.com?node_id=890409

betterworld has asked for the wisdom of the Perl Monks concerning the following question:

I tried using Regexp::Grammars together with MooseX::Declare, and the result was… a segfault. My code is:

#!/usr/bin/perl use MooseX::Declare; my $gr = do { use Regexp::Grammars; qr { <Foo> <objrule: Foo> foo }x; }; class Foo { method BUILD { use Data::Dumper; print 'AH ', Dumper \@_; } } my $m = 'foo' =~ $gr or die 'no match';

The output of this program is:

AH $VAR1 = [ bless( {}, 'Foo' ), { '@' => {}, '!' => '-1' } ]; Segmentation fault

These strange hash keys ("@" and "!") seem to be some internal values of Regexp::Grammars. I see nothing about them in the documentation, so I'd say their exposure is a bug. However this does not seem to have anything to do with the segfault: The grammar calls the Foo constructor like in the following, but it won't segfault if I do so manually:

Foo->new( { '@' => {}, '!' => '-1' } );

Also, the segmentation fault disappears if I do either of:

I should probably report a bug somewhere. However I am unsure where it should be reported. Regexp::Grammar itself does not seem to use any XS or lowlevel stuff, so it is probably not the problem. However, it uses many funny features of the new regexp engine. MooseX::Declare on the other hand uses a whole bunch of modules with a lot of magic in them. Maybe you can help me pinpoint the origin of this bug.

I use perl v5.10.1, MooseX::Declare 0.34, Regexp::Grammars 1.012, all current Debian wheezy versions.

Replies are listed 'Best First'.
Re: Segfault with MooseX::Declare and Regexp::Grammars
by Anonymous Monk on Feb 27, 2011 at 13:08 UTC
    On win32 I get the same, but this also disappears if I use Data::Dump or Data::Dump::Streamer instead of Data::Dumper

    Running under the debugger, I get

    Signal SEGV at (reeval 422)[pm.890409.pl:30] line 1
    on the 10th iteration.

    With Devel::Trace it happens after

    So I think it could be a bug in Dumpxs, or the perl regexp engine, or both.

      This cannot be a bug in Data::Dumper: If I remove the dumping code (so BUILD is empty), the segmentation fault still happens. Sorry I did not mention this. I was so accustomed to Data::Dumper that I did not suspect a bug there :)

        You're not the only one to load Data::Dumper :)
        print "AH Data::Dumper::VERSION $Data::Dumper::VERSION @_\n" +;
        AH Data::Dumper::VERSION 2.128 Foo=HASH(0x1bc0a2c) HASH(0x1bc0afc)
        Data::Dumper may or may not be responsible, directly or otherwise ... someone needs to bust out a debugger and track down where the segfault occurs
Re: Segfault with MooseX::Declare and Regexp::Grammars
by ELISHEVA (Prior) on Feb 27, 2011 at 13:12 UTC

    Maybe you can help me pinpoint the origin of this bug.

    Have you tried rewriting your program to use plain old Perl objects (no Moose::Declare)? Do you still get a segfault?

    If not, then I'd start looking at Moose::Declare, beginning with the smallest possible grammar ( can you have a null grammar qr{} - what happens when you do?) and building up until you see the weird behavior. Try each grammar out with your pure Perl object and with a Moose object, noting when both fail, one fails or the other fails.

    If you can reproduce the problem without MooseX::Declare then either something about the way you are using Regexp::Grammars is at issue, or as you say, there is a bug.

      Have you tried rewriting your program to use plain old Perl objects (no Moose::Declare)

      As stated above, the issue disappears when I get rid of MooseX::Declare and use plain Moose or even plain objects like this:

      { package Foo; sub new { use Data::Dumper; print 'AH ', Dumper \@_; return bless {}; } }
      can you have a null grammar qr{}

      I need the "objrule" to have Regexp::Grammars call the constructor, so the grammar cannot be reduced much further.

        If plain Perl objects and plain Moose objects don't cause this problem, could you clarify further what you are trying to pinpoint. What makes you unsure that this isn't an issue with MooseX::Declare and whatever magic it is conjuring up?

        It would seem to me that newer add-on packages like MooseX::Declare have a responsibility to work cleanly with core packages like Data::Dumper, as well as any non-core packages they extend (i.e. Moose). This is all the more so with something like MooseX::Declare which claims to be a safer way of doing the kinds of things people once tried to do with source filters.