Re: Embperl / Apache::Session bug?
On Tue, Nov 16, 1999 at 07:43:38PM +0100, Gerald Richter <[EMAIL PROTECTED]> muttered about RE: Embperl / Apache::Session bug?: > > > > Preloading Apache::Session also causes sigsegv'ing, this time while > > dealing with MD5.pm. Preloading nothing seems to work. > > > > And Embperl is _not_ loaded at startup time? Correct. > > When does SIGSEGV occurs, when the server starts, on the first Embperl > request or on the first request which uses %udat/%mdat? SIGSEGV always occurs when the server starts. > > The problem is when mod_perl is build with USE_DSO. Maybe the compiler > options does not match, for some of the modules (Perl, Apache, mod_perl, DBI > etc.). This seems likely, as the mod_perl and apache were installed from RPMs. When embperl was built, the headers I used were from an install of the apache SRPM. I will try rebuilding apache, mod_perl, apache::session, and embperl from pristine source and see what happens. > Building a staticly linked Apache will surely solve the problem, but > if you like to continue using the dynamic version, you can try the following > two things: > > 1.) Preload HTML::Embperl::Session SIGSEGV's when dealing with MD5.so. > 2.) Try Apache::Session::FileStore instead of DBIStore I'll try this later as well. > Gerald Thanks for your help, -aaron
RE: Embperl / Apache::Session bug?
> > Preloading Apache::Session also causes sigsegv'ing, this time while > dealing with MD5.pm. Preloading nothing seems to work. > And Embperl is _not_ loaded at startup time? When does SIGSEGV occurs, when the server starts, on the first Embperl request or on the first request which uses %udat/%mdat? The problem is when mod_perl is build with USE_DSO. Maybe the compiler options does not match, for some of the modules (Perl, Apache, mod_perl, DBI etc.). Building a staticly linked Apache will surely solve the problem, but if you like to continue using the dynamic version, you can try the following two things: 1.) Preload HTML::Embperl::Session 2.) Try Apache::Session::FileStore instead of DBIStore Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Embperl / Apache::Session bug?
Preloading Apache::Session also causes sigsegv'ing, this time while dealing with MD5.pm. Preloading nothing seems to work. -aaron On Tue, Nov 16, 1999 at 05:00:31PM +0100, Gerald Richter <[EMAIL PROTECTED]> muttered about RE: Embperl / Apache::Session bug?: > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > > Behalf Of Aaron Elkiss > > Sent: Tuesday, November 16, 1999 4:46 PM > > To: [EMAIL PROTECTED] > > Subject: Embperl / Apache::Session bug? > > > > > > Hi.. I'm trying to get session handling (%udat and %mdat) to work with > > embperl 1.2b11. > > > > I'm running stock redhat 6.1 on a p200; this comes with apache 1.3.9, > > mod_perl 1.21, and perl 5.00503. I installed embperl 1.2b11 and > > Apache::Session 1.04. I had previously installed and was using MySQL > > 3.22.27 with the latest version of DBI and DBD::mysql. > > > > Anyway, the symptoms are as follows: Everything works fine with > > embperl normally, but when I add the following lines to my srm.conf > > Bad Things Happen: > > > > PerlSetEnv EMBPERL_SESSION_CLASSES "DBIStore SysVSemaphoreLocker" > > PerlSetEnv EMBPERL_SESSION_ARGS "DataSource=dbi:mysql:session > > UserName=apache" > > > > Did you load Embperl and/or Apache::Session at server startup time? > > Please try to _not_ load Embperl at startup time and load Apache::Session at > startup time (e.g. PerlModule Apache::Session in your srm.conf) > > Gerald > > > > --- > Gerald Richter ecos electronic communication services gmbh > Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl > > E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 > WWW:http://www.ecos.de Fax:+49-6133/925152 > --- >
RE: Embperl / Apache::Session bug?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Aaron Elkiss > Sent: Tuesday, November 16, 1999 4:46 PM > To: [EMAIL PROTECTED] > Subject: Embperl / Apache::Session bug? > > > Hi.. I'm trying to get session handling (%udat and %mdat) to work with > embperl 1.2b11. > > I'm running stock redhat 6.1 on a p200; this comes with apache 1.3.9, > mod_perl 1.21, and perl 5.00503. I installed embperl 1.2b11 and > Apache::Session 1.04. I had previously installed and was using MySQL > 3.22.27 with the latest version of DBI and DBD::mysql. > > Anyway, the symptoms are as follows: Everything works fine with > embperl normally, but when I add the following lines to my srm.conf > Bad Things Happen: > > PerlSetEnv EMBPERL_SESSION_CLASSES "DBIStore SysVSemaphoreLocker" > PerlSetEnv EMBPERL_SESSION_ARGS "DataSource=dbi:mysql:session > UserName=apache" > Did you load Embperl and/or Apache::Session at server startup time? Please try to _not_ load Embperl at startup time and load Apache::Session at startup time (e.g. PerlModule Apache::Session in your srm.conf) Gerald --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
Embperl / Apache::Session bug?
Hi.. I'm trying to get session handling (%udat and %mdat) to work with
embperl 1.2b11.
I'm running stock redhat 6.1 on a p200; this comes with apache 1.3.9,
mod_perl 1.21, and perl 5.00503. I installed embperl 1.2b11 and
Apache::Session 1.04. I had previously installed and was using MySQL
3.22.27 with the latest version of DBI and DBD::mysql.
Anyway, the symptoms are as follows: Everything works fine with
embperl normally, but when I add the following lines to my srm.conf
Bad Things Happen:
PerlSetEnv EMBPERL_SESSION_CLASSES "DBIStore SysVSemaphoreLocker"
PerlSetEnv EMBPERL_SESSION_ARGS "DataSource=dbi:mysql:session UserName=apache"
The database exists, and the "sessions" table is set up as per the
Apache::Session::DBIStore documentation.
I performed a little bit of poking with strace and the single spawned
child httpd seems to be sigsegv'ing right after it stats Embperl.pm
and Embperl.bs, and before it attempts to open Embperl.. Here's a typical occurance:
Filehandle 5 is open("/usr/lib/perl5/site_perl/5.005/i386-linux/HTML/Embperl.pm",
O_RDONLY) = 5
Here's a cleaned-up version of what strace says about what's happening... (I've
cleaned out the multitude of brk(3)'s and rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =
0).
munmap(0x40215000, 4096)= 0
read(5, "isableHtmlScan => 512 ;\n"..., 4096) = 4096
read(5, "l \'use Apache::Constants qw(:com"..., 4096) = 4096
read(5, "lit (/&/, $info) ;\nmy $cnt ="..., 4096) = 4096
read(5, "e\'}= $ENV{EMBPERL_ESCMODE} }"..., 4096) = 4096
read(5, ": $@\" if ($@); \n\trequire CGI"..., 4096) = 4096
read(5, "\t{\n\tpush @cleanups, \'dbg"..., 4096) = 4096
read(5, "G \"i = $req{\'inputfile\'}\\n\" ;\n\n "..., 4096) = 4096
read(5, " {\n\tlocal(*ENTRY) = $val"..., 4096) = 4096
read(5, "\n\n$response = $ua->request($"..., 4096) = 4096
read(5, "= \\$HTML::Embperl::optDisabl"..., 4096) = 4096
read(5, "or $package\\:\\:$k -> $caller\\n\" "..., 4096) = 4096
read(5, " $ok and $ok = $smtp->datas"..., 4096) = 1190
read(5, "", 4096) = 0
close(5)= 0
munmap(0x40017000, 4096)= 0
stat("/usr/lib/perl5/5.00503/i386-linux/auto/HTML/Embperl", 0xbfffd898) = -1 ENOENT
(No such file or directory)
stat("/usr/lib/perl5/5.00503/auto/HTML/Embperl", 0xbfffd898) = -1 ENOENT (No such file
or directory)
stat("/usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Embperl",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Embperl/Embperl.so",
{st_mode=S_IFREG|0555, st_size=145024, ...}) = 0
stat("/usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Embperl/Embperl.bs",
{st_mode=S_IFREG|0444, st_size=0, ...}) = 0
--- SIGSEGV (Segmentation fault) ---
So it looks like it's reading embperl.pm, finishes with that, then
stats those other files for some reason, then crashes.
The exact same thing happens when those environment variables aren't
set, but it continues to do the following stuff:
stat("/usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Embperl/Embperl.bs", {
st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Embperl/Embperl.so", O
_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0555, st_size=145024, ...}) = 0
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320}\0"..., 4096) = 409
6
mmap(0, 130380, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0x40255000
mprotect(0x40271000, 15692, PROT_NONE) = 0
mmap(0x40271000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0x1b000) =
0x40271000
mmap(0x40274000, 3404, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
0) = 0x40274000
close(5)
and then it goes on to read and process the actual .epl source file.
If it's producing a core file when it sigsegv's, I can't find what it
did with it.
Any thoughts?
