Many thanks Roderich -- running this through the truss program revealed a file permissions problem in /tmp/wellnessworkdays/session_data. This PAR assembly had attempted using this existing directory that had previously been created by apache while I was running this application in the normal, non-PAR way (i.e. installing all perl dependencies, etc). This directory was the same one the PAR assembly wanted, but the permissions were www:wheel. Removing the directory and letting the PAR assembly re-create it did the trick!
Thanks again! On Sat, Nov 8, 2008 at 10:10 AM, Ben Sommer <[EMAIL PROTECTED]> wrote: > Thanks for the advice - I'll try all that. Thanks for looking at the code - > please tell me what specific additional information would make it easier to > diagnose anything else wrong. > > -----Original Message----- > From: "Roderich Schupp" <[EMAIL PROTECTED]> > To: "Ben Sommer" <[EMAIL PROTECTED]> > Cc: par@perl.org > Sent: 11/8/2008 10:03 AM > Subject: Re: parl generates a core dump > > On Sat, Nov 8, 2008 at 2:45 AM, Ben Sommer <[EMAIL PROTECTED]> wrote: > > Hi all -- no knowledge to share on this little core dump problem? Is > there a > > better place for me to ask the question? > > This _is_ the right place to field PAR questions. However, there's too > little information to diagnose the problem. > From the top of my head, I'd say that the program picks up other > stuff when run on the production machine than when run on development. > On production it might not pick up some of the stuff > in the par, but slightly incompatible stuff already installed. There > can be lots of reasons for that, e.g. different perl built-in > @INC paths, setting of $PERL5LIB, the highly suspicious line > > use lib "$FindBin::Bin/../lib"; > > in your main script and a dozen others. > > Try running your application under truss on both development and > production and examine the traces for differences which > modules and shared libraries are actually loaded. > > Cheers, Roderich >
