I suggest you post your segfaulting mod_perl program so that we can see if you're doing anything obviously wrong.

Segfaults with mod_perl are quite rare, in my experience. It's quite possible that you have some bad/mismatched packages. Fortunately, compiling your own apache/mod_perl/libapreq is pretty easy. Below are the steps I use for compiling - adjust as required:

The code I tried was the 4 lines from the Synopses: http://search.cpan.org/~joesuf/libapreq2-2.08/glue/perl/lib/Apache2/Request.pm#SYNOPSIS.

It turn out that it segfaults if you pass new a parameter value of undef. Clearly, that is not a working example, and there is no cross-reference or information on that page about where that value was supposed to have come from in the first place. Sure, I can look up Apache2::RequestRec but that tells me what methods are available, and continues to show a global $r that is assumed to simply exist without showing how you are supposed to declare and obtain it.

Ah, yes. That's a failure of assumption by the doc authors :), and really Apache2::Request should throw a proper error message instead of segfaulting in that situation. I'd raise a bug against that.

The reason I say assumption is that, for mod_perl programmers, $r is The One True Way of communicating with mod_perl, and so they have assumed that you know how to get hold of it. For somebody who is new to mod_perl, this is obviously not the case.

From the emails on the mod_perl mailing list, I assume that you have now sorted the issue out, but for clarification here, to get $r, which is an Apache2::RequestRec object, you would do the following:

• in ModPerl::Registry:

          my $r = Apache2::RequestUtil->request;
  [download]

• in a mod_perl handler:

          use Apache2::RequestRec ();
    
          sub handler {
              my $r = shift;
              ...
          }
  [download]

mod_perl 1 had a lot of good docs, a lot of which were written by Stas Bekman while Ticketmaster paid him to work on mod_perl. mod_perl 2 has a lot of good code, but the docs have been written by people who are intimately familiar with the internals. So everything is there, but not as clearly laid out as it could be. Also, everybody has full time jobs... you know how it goes.

However, they are very receptive to doc (and other) patches, so if you see ways to improve what we have already, feel encouraged to send patches through - they will be warmly welcomed.

Clint

http://perl.apache.org/docs/2.0/user/index.html
here you can get randy kobes discontinued apache2/perl distribution (has sample config with mason/tt2 ... )

Using "Registry" goes to some effort to run CGI scripts unchanged. I don't need that, as I'll write to the API. The "module" or "handler" is set up differently, with the Apache config file mapping a URL to the file to run, instead of the file just being there at that location. So you have to put every single such file into the configuration.

So you have to put every single such file into the configuration.

This is not necessarily the case. I tend to have a single entry point to my mod_perl application (a dispatcher), which handles everything below / except for (eg) paths to static content:

        <Location ~ "^/(?!img|stylesheets|scripts|robots.txt|favicon.i
+co|error).*" >
            SetHandler          perl-script
            PerlResponseHandler My::Dispatcher
        </Location>
[download]

and that single handler parses the request, then hands it off to the relevant handler in my code. Once that handler has processed the request, it passes back the relevant data, template name etc, and my dispatcher handles the template processing and returns the correct response.

This allows you to do pretty much everything in Perl, without having to worry too much about apache.

Sorry, it doesn't. Start following the book, and names are different in the Apache configuration file to begin with, and the second example script won't compile. There is another 'use' for a lot of compatibility, but you still have to change things. And I don't want to learn the deprecated way.