Re: TIPool / multiple database connections
Hi,
I am a little late for the thread, nevertheless I like to give experiences I
gathered trying to get DBI threadafe. As Stas already said before in this
thread I have made a patch to DBI which makes DBI threadsafe. The result is
released in DBI 1.30. This doesn't mean that the DBD driver can handles
this, but mostly it's not hard to add.
Threadsafe means not that you can share any sort of DBI handles. It's means
that it's safe to use DBI with threads and that it is made sure that every
intances of the Perl interpreter (i.e. every thread) gets it own instance of
DBI.
My inital goal was to share DBI handles between threads, but this would need
very much work inside DBI. Additionaly Perl does not yet support sharing of
objects (BTW share does not deep share data structures). So Tim suggested to
first make DBI work correctly with threads at all. That's what we have done.
Gerald
P.S. I have some experimental code to share database handles inside of
DBD::Oracle, since this was much easier to implement, but this is not quite
ready yet.
-
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 925131
WWW:http://www.ecos.de Fax: +49 6133 925152
-
- Original Message -
From: "Elizabeth Mattijsen" <[EMAIL PROTECTED]>
To: "Stas Bekman" <[EMAIL PROTECTED]>; "Perrin Harkins" <[EMAIL PROTECTED]>
Cc: "Tim Keefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 16, 2002 11:17 AM
Subject: Re: TIPool / multiple database connections
> At 02:57 PM 7/16/02 +, Stas Bekman wrote:
> >Perrin Harkins wrote:
> >>Hmmm... That could really throw a wrench in things. If you have an
> >>object based on a hash, and you share that hash, and you re-bless the
> >>object in each thread, does that work? What if the hash contains
> >>references to other variables. Do they need to be explicity shared as
well?
> >That's what I meant. Probably non need for Thread::Pool, at all. use a
> >shared datastructure, maintain a list of free and busy items and simply
> >hand pointers inside this datastructure to the threads asking for an
item.
> >e.g.:
> >
> >package DBI::Pool;
> >use threads::shared;
> >my @pool : shared;
> >sub init {} # pre-populate pool with N connections
> >sub get {} # return a ref to $dbh, grow the pool if needed
> >sub put {} # move the pointer from the busy list to the free list
>
> Hmmm... as long as you do this _before_ the (Apache) threads get started,
> this might work. I still haven't got my mind entirely around what one is
> allowed to do, what you can do and is allowed, what you can't do but is
> allowed and crashes, and what in principle is possible but you're barred
> from because of e.g. prototyping getting in the way.
>
>
> >won't this work? I guess Perrin is right in respect that the whole item
> >needs to be shared (deep-shared). can we have such an attribute/function
> >that will automatically traverse the datastructure and share it all? or
is
> >this the case already with 'shared'?
>
> Good question. I don't think it is deep shared and that's why it probably
> doesn't work. The way Thread::Queue::Any (which is the transport medium
> for Thread::Pool) handles this, is by serializing any data structure with
> Storable, pass that around and deserialize that on the other end.
>
>
> >Now since we want to have various connections, it can be:
> >my %pools : shared;
> >where each key is a unique identifier, "compiled" from the dbi connect's
> >DSN string and a value is the actual pool.
>
> That's an approach. If you could actually share the $sth objects. About
> which I have my doubts.
>
>
> >BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a
> >generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
> >things like connect_on_init(), but just to build the initial pool when
the
> >process starts.
>
> DBI::Pool would be ok. But unless I'm wrong about the sharing issues,
> you're going to be stuck, at least with this version of Perl, with
> serializing between threads.
>
>
> Liz
>
>
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Hi Josh, On Tue, 30 Jul 2002, Josh Chamas wrote: > Thanks for the feedback & still looking for more! Well for one thing you're doing a great job. :) Fo benchmarks to be more realistic, I feel that they need to include chunks of code to do lookups in serious databases, put together very complex pages, and make use of any chaching schemes which are likely to be available. That's a lot of work. Unless you're prepared to do something like that more or less for kicks, I think that what you've done up to now is about as good as it's going to get. 73, Ged.
Re: Mandrake defalut mod_perl dose not seem to be working.
Roy Souther wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wednesday 31 July 2002 08:40 pm, Stas Bekman wrote: > >>What do you mean by "doesn't work"? Try: >>http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_m >>od_perl_is_running_ > > The two tests they recommend give conflicting results. The log file says that > mod_perl was started. The command line test "httpd -l" says it is not > compiled in. The problem here is that mod_perl and apache doc recommend that > you disable httpd and run httpd_modperl in it's place but Mandrake runs both > httpd and httpd-perl that is the binary they ship with mod_perl. They must > have renamed it. They both of them and each has it's own set of configuration > files. So I did wget -S 127.0.0.1 and the mod_perl does not show there. So I > can not confirm that mod_perl is running or not. I use Mandrake but I never use apache/mod_perl rpms but build my own, so I don't know. But it seems that you test the wrong binary 'httpd -l', if error_log says that you are running mod_perl you are running mod_perl. > Is there a simple test file I could use to see if it is running? Or some other > test I could do? Configure a registry section http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server and run a simple script: http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Mandrake defalut mod_perl dose not seem to be working.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 31 July 2002 08:40 pm, Stas Bekman wrote: > What do you mean by "doesn't work"? Try: > http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_m >od_perl_is_running_ The two tests they recommend give conflicting results. The log file says that mod_perl was started. The command line test "httpd -l" says it is not compiled in. The problem here is that mod_perl and apache doc recommend that you disable httpd and run httpd_modperl in it's place but Mandrake runs both httpd and httpd-perl that is the binary they ship with mod_perl. They must have renamed it. They both of them and each has it's own set of configuration files. So I did wget -S 127.0.0.1 and the mod_perl does not show there. So I can not confirm that mod_perl is running or not. Is there a simple test file I could use to see if it is running? Or some other test I could do? - -- Roy Souther <[EMAIL PROTECTED]> http://www.SiliconTao.com "the future of supercomputers is all Linux, and nothing but Linux." - www.it-director.com Feb 2002 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1IruMACgkQCbnxcmEBt41dqgCguE2KsggkciZ0TPl5pHYkaWgL 1ooAn2IbzDhvUsum3zB95qVDGsQyyI5L =nxHS -END PGP SIGNATURE-
Re: Mandrake defalut mod_perl dose not seem to be working.
Roy Souther wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Trying to get HTML::Mason going and I have been told that my problem is that
> mod_perl is not running. I was told to test the value of $ENV{MOD_PERL} in a
> cgi script and if it return true then it was working properly but it did not.
>
> I have gone over the apache conf files many times all day today and they seem
> to be correct with the mod_perl documentation but it does not work. The
> system is Mandrake 8.2.
>
> Reading the log files there does not seem to be any error but their are
> entries for the starting and stopping of apache.
>
> I am at a loss. I have installed all the Mandrake rpms and checked the conf
> files.
>
> Does anyone have mod_perl working on a Mandrake system?
> Any ideas for things that could be wrong?
What do you mean by "doesn't work"? Try:
http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_mod_perl_is_running_
If it's not, then check that you've enabled mod_perl (you have to
actually change httpd.conf to enable mod_perl). This short doc should
get you up to speed:
http://perl.apache.org/docs/1.0/guide/getwet.html
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails
John E. Mendenhall wrote: > I have compiled mod_perl 1.27 with apache 1.3.26 under perl 5.6.1, solaris > 2.6. When I run the make test, it fails with the following in the > error_log: [...] > Received signal #11, SIGSEGV [caught] > siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 Please send the backtrace for this segfault. http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems or try Debug::SIGSEGVTrace which I've just released on CPAN. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ANNOUNCE: Debug::SIGSEGVTrace
Stas Bekman wrote: > For all those who have troubles getting a backtrace or the core file, > when a mod_perl server (or a perl program) segfaults, here is a module > that attempts to do all the work for you. The rest of the doc follows. > Please read the TODO section, and help me with things that need to be > done if you know how. Thanks. > > I've just uploaded it on CPAN, so it'll take a while before it gets > mirrored, but you can get it from here: > https://pause.perl.org/pub/PAUSE/authors/id/S/ST/STAS/Debug-SIGSEGVTrace-0.01.tar.gz Oops, I haven't realized that this URL is passwd protected. Anyway it's on CPAN now: http://search.cpan.org/search?mode=module&query=SIGSEGVTrace -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
Barrie Slaymaker <[EMAIL PROTECTED]> wrote: >On Wed, Jul 31, 2002 at 07:25:48PM -0500, James G Smith wrote: >> XML::SAX::Machines > >This is an XML SAX processing framework, nothing to do with state machines I'm >afraid. I do have another distribution (not on CPAN, let me know if you want a >copy) in the StateML:: namespace that takes an XML definition for a state >machine and uses it, via TT2, to generate any kind of source code (we use it >for gnu and embedded C compilers here). It also generates pretty diagrams >using GraphViz. My apologies. The name `Machines' coupled with a configuration that looked suspiciously like a list of states and edges must have tripped by `state-machine-ometer' and caused me to add it to the list. I was basing most of my decisions on a cursory look at the documentation (after all, there were 2200+ search results...) and not on any in-depth use (except perhaps POE, which I've looked over a couple times recently). The StateML:: stuff does sound neat though :) I'm wanting to eventually put together a gui for creating web-based wizard-like applications -- draw the circles and the lines, hang a few requirements off the edges, and you almost have an app. And with the OO stuff, the apps can be sub-classed. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
On Wed, Jul 31, 2002 at 07:25:48PM -0500, James G Smith wrote: > XML::SAX::Machines This is an XML SAX processing framework, nothing to do with state machines I'm afraid. I do have another distribution (not on CPAN, let me know if you want a copy) in the StateML:: namespace that takes an XML definition for a state machine and uses it, via TT2, to generate any kind of source code (we use it for gnu and embedded C compilers here). It also generates pretty diagrams using GraphViz. - Barrie
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
Ron Savage <[EMAIL PROTECTED]> wrote: >On Wed, 31 Jul 2002 12:32:51 -0500, James G Smith wrote: >>James G Smith <[EMAIL PROTECTED]> wrote: >>>The distribution is available on CPAN (soon -- has been uploaded) >>>and >>>at http://sourceforge.net/project/gestinanna/ >> >>Make that http://sourceforge.net/projects/gestinanna/ > >There are some state machine modules in CPAN already, under the >prefix DFA:: for Discrete Finite Automata. Do we really need a >separate prefix StateMachine:: for this? Actually, state machines exist under DFA::, POE::, and a host of other specialized name spaces. >For the record, DFA was suggested to me when I asked for module name >suggestions, because it (DFA) was already in use when I wanted to >submit my module. StateMachine:: was the most recent (actually, only) suggestion made on the modules@ list outside of POE::, but POE:: doesn't fit the type of machine I need. If it's strictly a DFA, then it could go under the DFA:: namespace just as well, though NFA:: would be a more-encompassing namespace :/. It is potentially non-deterministic. http://search-beta.cpan.org/modlist/Control_Flow_Utilities http://search-beta.cpan.org/search?mode=all&query=state+machine (finds 2200+ entries) of which the following seem to be genuine state machines (from the first 500 results). Bio::Tools::StateMachine::AbstractStateMachine Bio::Tools::StateMachine::IOStateMachine CGI::MxScreen Decision::Markov DFA::Command DFA::Kleene DFA::Simple POE::NFA POE::Session Set::FA Wizard::State XML::SAX::Machines -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: $r->dir_config->(un)set issue...
On Wed, 2002-07-31 at 21:33, Geoffrey Young wrote:
>
>
> simran wrote:
>
> > Does that mean that
> >
> > $r->dir_config is not the same as $r->server->dir_config ?
> >
> > A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
>
> I looked into implementing that the last time it came up but IIRC it
> would take redoing the merge routines - from what I remember I got
> PerlUnsetVar to work at conf parse time, but it ended up being
> repopulated at request time when the directory merger ran (to merge
> $r->server->dir_config and $r->dir_config I think).
>
> calling unset() manually is probably your best bet.
>
I wouldn't mind using that, except that it does not work for me... (i
have copied a part of the original message below as that got snipped...)
I have a situation where it is convinent for me to define a global
"PerlSetVar" in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
httpd.conf
--
use Apache::Server;
Apache->server->dir_config->unset("MyVar");
-
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r->dir_config(MyVar => undef);
5.
6.$r->dir_config->unset("MyVar");
7.
8.$r->dir_config->set(MyVar => undef);
9.
10. }
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a "true" value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
On Wed, 31 Jul 2002 12:32:51 -0500, James G Smith wrote: >James G Smith <[EMAIL PROTECTED]> wrote: >>The distribution is available on CPAN (soon -- has been uploaded) >>and >>at http://sourceforge.net/project/gestinanna/ > >Make that http://sourceforge.net/projects/gestinanna/ There are some state machine modules in CPAN already, under the prefix DFA:: for Discrete Finite Automata. Do we really need a separate prefix StateMachine:: for this? For the record, DFA was suggested to me when I asked for module name suggestions, because it (DFA) was already in use when I wanted to submit my module. -- Ron Savage, [EMAIL PROTECTED] on 1/08/2002
Mandrake defalut mod_perl dose not seem to be working.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trying to get HTML::Mason going and I have been told that my problem is that
mod_perl is not running. I was told to test the value of $ENV{MOD_PERL} in a
cgi script and if it return true then it was working properly but it did not.
I have gone over the apache conf files many times all day today and they seem
to be correct with the mod_perl documentation but it does not work. The
system is Mandrake 8.2.
Reading the log files there does not seem to be any error but their are
entries for the starting and stopping of apache.
I am at a loss. I have installed all the Mandrake rpms and checked the conf
files.
Does anyone have mod_perl working on a Mandrake system?
Any ideas for things that could be wrong?
- --
Roy Souther <[EMAIL PROTECTED]>
http://www.SiliconTao.com
Nine out of ten sysadmins recommend
Linux for your servers longevity!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj1IZ7kACgkQCbnxcmEBt41/EACgzoMjLbvN1bQF+wEm6R2dlbdj
nzAAnRDGJezx0ul9HQXp5Z+7JILsaM/j
=YTqG
-END PGP SIGNATURE-
Re: Problems with Apache/Mod_perl Server
My apologies. Thought I posted to the list Thanks for the help. Alfred, Alfred Vahau wrote: > The server's up and running. > > Thanks for the /etc/hosts tip > > I actually had the line as > > 127.0.0.1 bullen localhost.localdomain localhost > > So I commented out that and entered it as > > 127.0.0.1 localhost.localdomain localhost > > and sure enough that served the Apache page as it should for the first time. > > I appreciate the help. I will continue to look into Perl 5.6.0 and 5.6.1 paths > though. Good, but please reply to the list, so others know that your problem has been solved. > --- > > This is off topic but ever hear of the site naver.com? The postings to modperl > had been intercepted and returned to me with encrypted messages and a naver.com > site with Korean or Japanese characters. Not a clue about the site. I suspect > that this posting is going to be intercepted and copied to me. Wonder if its a > robot? no clue > --- > > Alfred, > > Stas Bekman wrote: > > >>Alfred Vahau wrote: >> >>>Thanks for the leads. My concentration definitely lapsed over the make test >>>failure. >>>I ran make install regardless and all was well. I attempted to start the >>>server without success. >>>Here's the error message from the error_log >>> >>>[Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's >>>fully qualified domain name, using 127.0.0.1 for ServerName >> >>add to /etc/hosts: >>127.0.0.1 localhost.localdomain localhost >> >> >>>[Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid >>>overwritten -- Unclean shutdown of previous Apache run? >>>[Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 >>>configured -- resuming normal operations >>>[Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) >> >>So it starts normally. >> >> >>>perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas >>>I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may >>>have to try installing Perl 5.6.1 again. >>>I'll report the results. >> >>If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have >>installed perl into /usr/local/bin and /usr/bin comes earlier in the >>path so it picks 5.6.0. >> >>Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries >>though I can see that you will have dependencies problems. >> >>__ >>Stas BekmanJAm_pH --> Just Another mod_perl Hacker >>http://stason.org/ mod_perl Guide ---> http://perl.apache.org >>mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com >>http://modperlbook.org http://apache.org http://ticketmaster.com > -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting serverfails
I have compiled mod_perl 1.27 with apache 1.3.26 under perl 5.6.1, solaris
2.6. When I run the make test, it fails with the following in the
error_log:
[notice] Destruction->DESTROY called for $global_object
Prototype mismatch: sub Socket::INADDR_ANY vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 329.
Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 330.
Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 331.
Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 332.
[Wed Jul 31 14:12:36 2002] [warn] [notice] child_init for process 10483, report any
problems to [no address given]
This might all be fine and good, but when the test tries to retrieve the
test.html document, the server immediately stops, with no other messages
anywhere. If I start the httpd daemon separately from running the tests
(make start_httpd), it starts just fine. If I attach a truss to the
single process (running under -X), then run the tests (make run_tests), I
get these errors:
--- truss log ---
# truss -p 10483
accept(16, 0xE8F0, 0xE8EC) (sleeping...)
accept(16, 0xE8F0, 0xE8EC) = 3
fcntl(17, F_SETLKW64, 0x001994C8) = 0
sigaction(SIGUSR1, 0xE730, 0xE830) = 0
getsockname(3, 0xE900, 0xE8EC) = 0
setsockopt(3, 6, 1, 0xE86C, 4) = 0
brk(0x006E9000) = 0
brk(0x006EB000) = 0
brk(0x006EB000) = 0
brk(0x006ED000) = 0
alarm(300) = 0
read(3, " G E T / t e s t . h t".., 4096) = 98
sigaction(SIGUSR1, 0xEFFFD640, 0xEFFFD740) = 0
time() = 1028149998
alarm(300) = 300
alarm(0)= 300
stat64("/usr/local/src/mod_perl/mod_perl-1.27/t/docs/test.html",
0x006E91E8) = 0
open64("/usr/local/src/mod_perl/mod_perl-1.27/t/.htaccess", O_RDONLY)
Err#2 ENOENT
open64("/usr/local/src/mod_perl/mod_perl-1.27/t/docs/.htaccess", O_RDONLY)
= 5
fstat64(5, 0xE5C0) = 0
fstat64(5, 0xEFFFD420) = 0
brk(0x006ED000) = 0
brk(0x006EF000) = 0
ioctl(5, TCGETA, 0xEFFFD3AC)Err#25 ENOTTY
read(5, " ", 8192) = 1
read(5, 0x006EB104, 8192) = 0
read(5, 0x006EB104, 8192) = 0
llseek(5, 0, SEEK_CUR) = 1
close(5)= 0
Incurred fault #6, FLTBOUNDS %pc = 0x0002D6F0
siginfo: SIGSEGV SEGV_MAPERR addr=0x0018
Received signal #11, SIGSEGV [caught]
siginfo: SIGSEGV SEGV_MAPERR addr=0x0018
sigprocmask(SIG_SETMASK, 0xEF567D90, 0x) = 0
sigaction(SIGSEGV, 0xE140, 0x) = 0
sigprocmask(SIG_SETMASK, 0xEF570A90, 0x) = 0
setcontext(0xE300)
Incurred fault #6, FLTBOUNDS %pc = 0x0002D6F0
siginfo: SIGSEGV SEGV_MAPERR addr=0x0018
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x0018
*** process killed ***
#
--- truss log end ---
I have used mod_perl up through versions 1.15, using perl 5.004_04,
earlier versions of Apache. I am trying to upgrade to the latest stable
releases of everything and it just does not seem to be working. I have
checked the list archives as well as google and anywhere else I could
think of and could not find why it is dying. Any help is appreciated.
Thank you very much.
JohnM
## John Mendenhall
## [EMAIL PROTECTED]
## Senior Network/Systems Administrator
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perrault wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On July 30, 2002 10:02 pm, Stas Bekman wrote: > >>2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html >>Though you can really rely on it once Apache::Test is released, which >>will happen when mod_perl 2.0 is released. >>1) That's an interesting problem. It seems that nobody has asked this >>question before. Here is my take on it. If you like this solution I'll >>add it to the docs. > > > Thanks a lot. Your solution for Apache::DBI works and is very Perlish! Great. I've put it here: http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
FW: silent failure still a problem in mod_perl 2.0?
Kyle Dawkins writes: > I'd betcha your problem is almost certainly caused by your use of DSOs. If > you *really* want to prune your system down to see where your bug is, then > build apache and mod_perl statically. There was a very well-known bug that > caused DBI to segfault if it was run under a DSO. Please rebuild your > binary and then let us know if that was the problem. I just ran into the silent-failure problem again today, when a sysadmin unknowingly upgraded glibc underneath mod_perl built as a DSO. Unfortunately, it was on a production system; fortunately, it was not on a very important production system, and rebuilding the tools fixed the problem. In anticipation of the postmortem meeting, I'm trying to find out if this problem still exists in mod_perl 2.0. Websearches have been fruitless; any pe[a]rls of wisdom from the list? Charlton
silent failure still a problem in mod_perl 2.0?
Kyle Dawkins writes: > I'd betcha your problem is almost certainly caused by your use of DSOs. If > you *really* want to prune your system down to see where your bug is, then > build apache and mod_perl statically. There was a very well-known bug that > caused DBI to segfault if it was run under a DSO. Please rebuild your > binary and then let us know if that was the problem. I just ran into the silent-failure problem again today, when a sysadmin unknowingly upgraded glibc underneath mod_perl built as a DSO. Unfortunately, it was on a production system; fortunately, it was not on a very important production system, and rebuilding the tools fixed the problem. In anticipation of the postmortem meeting, I'm trying to find out if this problem still exists in mod_perl 2.0. Websearches have been fruitless; any pe[a]rls of wisdom from the list? Charlton
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
James G Smith <[EMAIL PROTECTED]> wrote: >The distribution is available on CPAN (soon -- has been uploaded) and >at http://sourceforge.net/project/gestinanna/ Make that http://sourceforge.net/projects/gestinanna/ -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
[ANNOUNCE] StateMachine::Gestinanna 0.01
StateMachine::Gestinanna is a fairly simple state machine implementation that is driven by the application. It does not actually drive an application but provides hints as to what the application should do next. It is designed to be especially helpful in a Model/View/Controller web-application environment to help the controller decide which view should be used. However, it may also be used in other areas, such as traditional GUIs. StateMachine::Gestinanna supports inheritance (via @ISA) of state transition definitions and code triggered by those transitions. This allows the development of classes of applications. HAS-A relationships are not yet supported. The distribution is available on CPAN (soon -- has been uploaded) and at http://sourceforge.net/project/gestinanna/ -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Senior Software Applications Developer, Texas A&M CIS Operating Systems Group, Unix
Re: get_remote_host for mod_perl2
Tim Keefer wrote: > Hi All, > Any ideas for retrieving the users ip address within a mod_perl2 module? > mod_perl1 has $r->get_remote_host. Is their something similar in > mod_perl2? I've searched all the mod_perl2 docs on perl.apache.org and > couldn't find anything about this. in 2.0 it's: use Apache::Connection; $r->connection->remote_host(); I'm not sure why Doug renamed it, but I just committed a patch to the compat layer. will update the doc too. p.s. Lyle is working on automatic docs extraction from httpd header files. once this is done the 2.0 API will appear online. Currently use search t/ for API usage. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
get_remote_host for mod_perl2
Hi All, Any ideas for retrieving the users ip address within a mod_perl2 module? mod_perl1 has $r->get_remote_host. Is their something similar in mod_perl2? I've searched all the mod_perl2 docs on perl.apache.org and couldn't find anything about this. Thanks in advance, Tim Keefer
a new doc: Preparing mod_perl modules for CPAN
I've just added a new doc: "Preparing mod_perl modules for CPAN" http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html If you have useful input please send it to me. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ANNOUNCE: Debug::SIGSEGVTrace
For all those who have troubles getting a backtrace or the core file,
when a mod_perl server (or a perl program) segfaults, here is a module
that attempts to do all the work for you. The rest of the doc follows.
Please read the TODO section, and help me with things that need to be
done if you know how. Thanks.
I've just uploaded it on CPAN, so it'll take a while before it gets
mirrored, but you can get it from here:
https://pause.perl.org/pub/PAUSE/authors/id/S/ST/STAS/Debug-SIGSEGVTrace-0.01.tar.gz
Also notice that the distro includes Debug::SIGSEGVFault, which simply
segfaults with a nice trace. I use it for the testing and you can use it
for testing core files dumping.
NAME
Debug::SIGSEGVTrace - Extract A Backtrace on SegFault
SYNOPSIS
use Debug::SIGSEGVTrace;
use File::Spec::Functions;
my $tmp_dir = File::Spec::Functions::tmpdir;
my $trace = Debug::SIGSEGVTrace->new(
dir=> "$tmp_dir",
#verbose=> 1,
#exec_path => '/home/stas/perl/bin/perl',
#core_path_base => catfile($tmp_dir, "mycore"),
#command_path => catfile($tmp_dir, "my-gdb-command"),
#debugger => "gdb",
);
# enable the sighandler
$trace->ready();
# or simply:
Debug::SIGSEGVTrace->new(dir => "$tmp_dir")->ready;
DESCRIPTION
This module attempts to automatically extract a backtrace when a
segfault happens, rather then letting the core file be dumped. This has
the following benefits:
* no need to setup the environment to allow core file dumped.
Sometimes people just don't know how to set it up. Sometimes you
aren't allowed to set it up (e.g., when the webserver
environment is
not under your control).
* if many Perl programs are run in a row and more than one program
segfaults it's possible to collect all backtraces, rathen then
aborting the run on the first segfault or staying with only the
last
core file, which will overwrite all the previous ones. For example
consider a live webserver or a test suite which may segfault many
times for different reasons.
* for huge core files, this approach saves disk space. And can be a
saver when you don't have disk space left for various reasons
(passed the quota?), but still have a few kilo-bytes left.
METHODS
new()
my $trace = Debug::SIGSEGVTrace->new(
dir=> "$tmp_dir",
verbose=> 1,
exec_path => '/home/stas/perl/bin/perl',
core_path_base => catfile($tmp_dir, "mycore"),
command_path => catfile($tmp_dir, "my-gdb-command"),
debugger => "gdb",
);
Attributes:
*dir*
a writable by the process directory.
This is a required attribute.
*verbose*
Whether to be silent (0) or verbose (1).
This is an optional attribute. The default is 0.
Currently it's always a non-verbose, with just a few traces printed
out. Will work in the future.
*exec_path*
"gdb" needs to know the path to the executable in order to
attach to
the process (though gdb 5.2 and higher needs only pid to do that).
This module is trying to automatically figure out the executable
path, using several methods in the following order:
$^X, /proc/self/exe, $Config{perlpath}
If all these methods fail the module will die(), unless you
explicitly set the *exec_path* attribute. Notice I named it
*exec_path* because the executable doesn't have to be perl, when
Perl is embedded, which is the case with mod_perl, which sets "$^X"
to the path to the Apache httpd server.
*core_path_base*
The base path of the core file. e.g. if *core_path_base* is set to
*/tmp/mycore* and the pid of the process that has segfaulted is
12345, the generated core is written to the file
*/tmp/mycore12345*.
This is an optional attribute.
By default *core_path_base* is a concatenation of the *dir*
attribute and the string *core.*.
*command_path*
The path to the file with debugger commands. If this attribute is
set the file should already include the commands. Notice that the
commands should include 'quit' as the last command, so the debugger
will quit.
This is an optional attribute.
By default *command_path* is a concatenation of the *dir* attribute
and the string *gdb-command*, which is getting populated with the
following commands:
bt
quit
*debugger*
Curently not used. In the future could be used to specify which
debugger to use (when more than one debugger is supported). For the
future compatibility "gdb" i
Unsuscribed
MSN Photos is the easiest way to share and print your photos: Click Here
unsubscibe
hi could someone please tell me how to unsubscibe? anoukChat with friends online, try MSN Messenger: Click Here
Re: Mention LoadFile in the mp2 docs?
On Tue, 30 Jul 2002, Stas Bekman wrote: > Alessandro Forghieri wrote: > > Greetings. > > > > From: > > http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl > > > > [...] > > Win32 users need to make sure that the path to the Perl binary (e.g., > > C:\Perl\bin) is in the PATH environment variable. > > [...] > > > > Is it not true that the directive LoadFile "C:\foo\perl58.dll" makes path > > modifications unnecessary? > > I guess the generic doc should simply redirect win32 users to > http://perl.apache.org/docs/2.0/os/win32/config.html > and not bother providing incomplete info. > > But I don't see that doc mentioning this issue. Randy? That's a good idea ... I'm at a workshop right now, but when I get back I'll add that. -- best regards, randy
Another Great Article by Stas!
I just wanted to give Kudos to Stas for his latest Mod Perl installment at Perl.com! http://www.perl.com/pub/a/2002/07/30/mod_perl.html Regards, KAM
Re: Warnings clarification
William McKee wrote: > On 31 Jul 2002 at 20:56, Stas Bekman wrote: > >>Have you read this? >>http://perl.apache.org/docs/1.0/guide/porting.html#Warnings > > > No, I was reading this-- > http://perl.apache.org/docs/1.0/guide/debug.html#The_Importance_of_Warnings > > The information in the link you posted is I was seeking. Perhaps a cross-reference > would be useful. I just added it. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Warnings clarification
On 31 Jul 2002 at 20:56, Stas Bekman wrote: > Have you read this? > http://perl.apache.org/docs/1.0/guide/porting.html#Warnings No, I was reading this-- http://perl.apache.org/docs/1.0/guide/debug.html#The_Importance_of_Warnings The information in the link you posted is I was seeking. Perhaps a cross-reference would be useful. Thanks, William -- Lead Developer Knowmad Services Inc. || Internet Applications & Database Integration http://www.knowmad.com
Re: Warnings clarification
William McKee wrote: > Hi, I've been using Perl for several years to develop simple CGI applications for my > clients. I'm now in the process of migrating to mod_perl for the performance benefit > it gives. In so doing, I've been lurking on this list and reading the Guide. > > Presently, I'm trying to debug a problem with a segmentation fault in the Petal > module that Jean-Michel Hiver announced a couple weeks ago on this list. As I was > reading the guide, "The Importance of Warnings" section in the Debugging chapter, > suggested setting PerlWarn On on the development machine. My question is > whether this setting is the same as the -w switch and the 'use warning' pragmas. I > suspect it is, but the guide did not clarify this point. Have you read this? http://perl.apache.org/docs/1.0/guide/porting.html#Warnings If yes, what part you are still confused about? I think the definitions are very clear. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote: > hi, > > this problem is stranger > when i use apache 1.3/modperl 1.27 this problem don't exist > > i think problem is because thread in apache2 or modperl2 That's the thing. I've had the same behavior with apache 1.3/modperl 1.27, so I don't think this has anything to do with Apache or mod_perl. (This is on linux) > lynx dont have problem because is other instance > if you open 2 instances of mozilla you dont have problem > but if you open one mozilla and 5 tab navigator of instance > problem persist > > []s > > nattis > Stas Bekman wrote: > >> Stas Bekman wrote: >> >>> Alessandro Forghieri wrote: >>> Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different : Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. >>> >>> >>> >>> >>> OK, I've returned to this problem. And the bug is in Apache 2.0 not >>> mod_perl. I was able to reproduce the serialization problem with a >>> plain cgi-bin script. Will report to the httpd-dev list and hopefully >>> it'll be resolved in the future version. >> >> >> >> I'm taking my words back. I did some more testing and the same problem >> can be reproduced with Apache 1.3. So I have tried different browsers >> and chased the problem to be a browser's fault. Here is the status on >> linux: >> >> Opera, Mozilla, Galeon - serialize the requests to the same URL. >> Konqueror, lynx- run both in parallel. >> >> Luckily I didn't sent the bogus bug report to httpd-dev ;) >> >> __ >> Stas BekmanJAm_pH --> Just Another mod_perl Hacker >> http://stason.org/ mod_perl Guide ---> http://perl.apache.org >> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com >> http://modperlbook.org http://apache.org http://ticketmaster.com >> >> >> > > -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
hi, this problem is stranger when i use apache 1.3/modperl 1.27 this problem don't exist i think problem is because thread in apache2 or modperl2 lynx dont have problem because is other instance if you open 2 instances of mozilla you dont have problem but if you open one mozilla and 5 tab navigator of instance problem persist []s nattis Stas Bekman wrote: > Stas Bekman wrote: > >> Alessandro Forghieri wrote: >> >>> Greetings. >>> >>> I have observed the same behavior (on win32). >>> >>> Scripts that are invoked from the same browser through the same URL >>> appear >>> to bind to the same perl thread and are therefore serialized. >>> Changing the URL appears to bind >>> the request to a different thread. (My observation regarded access >>> from a >>> different : Udei's experience shows that a URL change >>> suffices). >>> >>> I have often wondered wether this is incidental or specified behaviour. >> >> >> >> OK, I've returned to this problem. And the bug is in Apache 2.0 not >> mod_perl. I was able to reproduce the serialization problem with a >> plain cgi-bin script. Will report to the httpd-dev list and hopefully >> it'll be resolved in the future version. > > > I'm taking my words back. I did some more testing and the same problem > can be reproduced with Apache 1.3. So I have tried different browsers > and chased the problem to be a browser's fault. Here is the status on > linux: > > Opera, Mozilla, Galeon - serialize the requests to the same URL. > Konqueror, lynx- run both in parallel. > > Luckily I didn't sent the bogus bug report to httpd-dev ;) > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > > >
Warnings clarification
Hi, I've been using Perl for several years to develop simple CGI applications for my clients. I'm now in the process of migrating to mod_perl for the performance benefit it gives. In so doing, I've been lurking on this list and reading the Guide. Presently, I'm trying to debug a problem with a segmentation fault in the Petal module that Jean-Michel Hiver announced a couple weeks ago on this list. As I was reading the guide, "The Importance of Warnings" section in the Debugging chapter, suggested setting PerlWarn On on the development machine. My question is whether this setting is the same as the -w switch and the 'use warning' pragmas. I suspect it is, but the guide did not clarify this point. Thanks, William -- Lead Developer Knowmad Services Inc. || Internet Applications & Database Integration http://www.knowmad.com
Re: $r->dir_config->(un)set issue...
simran wrote: > Does that mean that > > $r->dir_config is not the same as $r->server->dir_config ? > > A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-) I looked into implementing that the last time it came up but IIRC it would take redoing the merge routines - from what I remember I got PerlUnsetVar to work at conf parse time, but it ended up being repopulated at request time when the directory merger ran (to merge $r->server->dir_config and $r->dir_config I think). calling unset() manually is probably your best bet. --Geoff
Re: how to unsubscribe
Hendrik Janse van Rensburg writes: > could someone please tell me how to unsubscibe? Look into the mail-headers
how to unsubscribe
hi could someone please tell me how to unsubscibe? cheers *** This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. ***
Re: $r->dir_config->(un)set issue...
simran wrote: > Does that mean that > > $r->dir_config is not the same as $r->server->dir_config ? not the same, $r->dir_config is a merge of the Location section setting with Server/Vhost settings, $r->server->dir_config is only for Server/Vhost settings. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can you have mod_perl 1.26 with Apache 2.0.39?
Grant Cooper wrote: > Can you have mod_perl 1.26 with Apache 2.0.39? > > I was unable to to install mod_perl from ports but was able to do a > pkg_install mod_perl 1.26. Seems to work now but now I have apache version > 1.3.22 where I use to have 2.0.39. Is this because mod_perl 2.0 is meant for > apache 2 and is not compatible with 1.3.22? I can't find any compatibility > documentation. No, you cannot mix these, see: http://perl.apache.org/docs/2.0/user/help/help.html#Wrong_Apache_mod_perl_combination Whenever you have a problem, remember to peruse the shortcuts menu on the left side of all pages at perl.apache.org and one of the two entries should save you (and us) a lot of time: Report 1.0 Problems Report 2.0 Problems __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
Stas Bekman wrote: > Alessandro Forghieri wrote: > >> Greetings. >> >> I have observed the same behavior (on win32). >> >> Scripts that are invoked from the same browser through the same URL >> appear >> to bind to the same perl thread and are therefore serialized. Changing >> the URL appears to bind >> the request to a different thread. (My observation regarded access from a >> different : Udei's experience shows that a URL change >> suffices). >> >> I have often wondered wether this is incidental or specified behaviour. > > > OK, I've returned to this problem. And the bug is in Apache 2.0 not > mod_perl. I was able to reproduce the serialization problem with a plain > cgi-bin script. Will report to the httpd-dev list and hopefully it'll be > resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Can you have mod_perl 1.26 with Apache 2.0.39?
Can you have mod_perl 1.26 with Apache 2.0.39? I was unable to to install mod_perl from ports but was able to do a pkg_install mod_perl 1.26. Seems to work now but now I have apache version 1.3.22 where I use to have 2.0.39. Is this because mod_perl 2.0 is meant for apache 2 and is not compatible with 1.3.22? I can't find any compatibility documentation.
Re: section: under - whats wrong here?
Hi Stas,
Thank you for your reply!
It worked like a charm! I can't believe I didn't try that: %Directory
vs. $Directory --- RTFM!
Peter
Stas Bekman
cc: [EMAIL PROTECTED]
Subject: Re: section:
under - whats wrong
07/30/2002 here?
10:17 AM
Peter, there are two problems:
1. you misread the usage explanations
It cannot be:
$Directory = { }
it must be:
%Directory = ().
Reread
http://modperl.com:9000/book/chapters/ch8.html#Configuring_Apache_with_Perl
again for the explanation.
here is a workaround that should solve your problem:
$Directory{'/usr/local/httpd/htdocs/capmon/'} = {
FilesMatch => {
'\.pl$' => {
'Options'=> '+ExecCGI',
'SetHandler' => 'perl-script',
'PerlSendHeader' => 'On',
'PerlHandler'=> 'Apache::Registry'
},
},
};
Re: while - modperl 2.0/Apache 2.0
Alessandro Forghieri wrote: > Greetings. > > I have observed the same behavior (on win32). > > Scripts that are invoked from the same browser through the same URL appear > to bind to the same > perl thread and are therefore serialized. Changing the URL appears to bind > the request to a different thread. (My observation regarded access from a > different : Udei's experience shows that a URL change suffices). > > I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
