Re: Trouble with Apache::DB
Yes, I was using the stock RH perl. I did try recompiling 5.8.0 with debugging support, as you suggested, with no luck. I then tried recompiling other versions of perl (like 5.8.0 RC2, RC1, 5.7.3), with and without debugging support, also with no luck. Finally, I just grabbed a 5.6.1 (since this all worked on my other systems with 5.6.1) and put that on there. I compiled without debugging support (and just used almost all the defaults), recompiled mod_perl and Apache, and that seems to have done the trick. I still don't know what the problem is, whether it's with perl, Apache::DB, RH, me, my cat... Anyway, I'll have to use this workaround until I have more free time. Thanks to everyone for the suggestions! --kip --- William McKee <[EMAIL PROTECTED]> wrote: > On 24 Oct 2002 at 23:35, John Siracusa wrote: > > I got a similar error a while back when I tried it > with the same versions > > of Perl, mod_perl, and apache (but on Mac OS X). > I googled a while and all > > I could come up with were some posts from > internals hackers about perl data > > structures getting mysteriously hosed for some > unknown reason with this > > collection of versions. I still haven't found a > solution... > > I think someone recently mentioned on this list that > you may need a Perl > with debugging compiled into it. Kip, are you using > the stock Redhat Perl? > Maybe you should try recompiling with debugging > enabled. That means you'll > need to recompile mod_perl as well. For my part, I > haven't had a problem > with the Debian 3.0 or FreeBSD perl binaries. > __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Trouble with Apache::DB
I have a newly installed Red Hat 8.0 system, with the following characteristics: * Perl v5.8.0 * mod_perl 1.27 * Apache 1.3.26 The build of mod_perl/Apache worked fine; the project I had been working on before upgrading RH seems to run ok. However, today I attempted to debug something using Apache::DB and running with "httpd -X". I received this error: [error] No DB::DB routine defined at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 4. Now, nothing has changed with my project (i.e. the Apache config is the same, the code is the same, etc), only the version of Perl on the new system. I did some tests using the regular perl debugger, and had no problems. Is there some incompatibility here, or is something else wrong? Any help would be greatly appreciated. Thanks, --kip __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Passing data among handlers
On: Tue, 30 Jan 2001 09:54:42 PST "Paul J. Lucas" wrote: > Perhaps I've missed it, but is there a better way than the > "notes" mechanism to pass data among handlers? > > The "notes" mechanism not only requires the notes to be > scalars, but, apparantly, said scalars must also be simple > strings, i.e., no binary data crammed into a scalar. > > Better ideas? Odds of enhancing the "notes" mechanism? > > - Paul > Try the "pnotes" mechanism. Very similar to "notes", but allows for complex data structures to be passed. For a while, it was an undocumented feature, but afaik is included in more recent dists (I'm running 1.24). --kip
Re: [OT] unsubscribe modperl
On: Fri, 10 Nov 2000 13:46:33 PST Paul wrote: >--- Dan & Oana <[EMAIL PROTECTED]> wrote: >> unsubscribe modperl > >I've seen several of these for the past day or two, and was going to >respond with instructions on how to go about unsubscribingand seem >to have deleted mine. How do I go about getting another copy of >list-command instructions? > >Paul > Go to http://perl.apache.org/#maillists for information. --kip
Re: redirecting large POSTs
On: Thu, 05 Oct 2000 09:45:30 EDT Drew Taylor wrote: > >Dare I ask what that 100MB consists of? That's a lot of uploaded data... >:-) > Pr0n, mostly :) Seriously, though, most of the information consists of CAD binary data (I work in the automotive industry), so we're talking large parts, assemblies, etc. from applications like Catia, I-deas, UG... --kip
Re: redirecting large POSTs
On: Wed, 04 Oct 2000 15:24:27 PDT [EMAIL PROTECTED] wrote: > >I was thinking about saving the posted data to a temporary file and >reading it back in after the login succeeds, but this seems messy and >error-prone. Has anyone else had this problem? Are there any modules >(maybe session mgmt stuff?) that could be easily adapted to handle this? > Hi Chris, I have the same problem, but have tried to solve it a bit differently than everyone else. I use a simple javascript function to check for the cookie that I expect. This function is envoked from an onSubmit handler from each I have, and if no cookie is found, a secondary login window is launched. Since my authentication and authorization handlers are integrated with mod_perl, if I detect that my cookie is not present, the javascript function pops up a secondary window containing my login page (the same one the user would see if they were redirected their from a GET). The user can then log in through that window, obtain the appropriate cookies, then go back to the original page and continue the form submission. Since the original page was never actually submitted, no data was sent, so no data need be stored anywhere. I did this because in my system, I routinely need to allow file uploads of 100MB or more. This is too unwieldy, IMO, to upload, store, retrieve, etc. So far, this has worked like a charm. --kip
[ OT - Job ]
We are looking for experienced mod_perl programmers for a large web application project. Startup environment, lots of autonomy, good $$. Other desired skills: Perl/XS, C, C++, database experience. The job is on-site, and we're in Dearborn, Michigan. If anyone's interested, please contact me at this email address. Thanks, --kip
Re: proxy requests via mod_proxy
On: Wed, 14 Jun 2000 12:30:50 EDT [EMAIL PROTECTED] wrote: >Hi, > >I'm using a "light weight" apache server compiled with mod_proxy >to pass dynamic requests off to my "heavy" mod_perl enabled >server. However, mod_proxy isn't forwarding the REMOTE_ADDR the >request originated from in the headers. I recall reading >reports that this is/was a known problem. Is there a patch for >mod_proxy that will have it include the originating IP in the >header? The mod_proxy version I'm using is the standard w/ >apache 1.3.12. > I use the same setup. Though I'm not aware of a patch to mod_proxy, I currently use a module written by Ask Bjoern Hansen called proxy_add_forward. Compiling this into your proxy server adds an X-Forwarded-For header to the proxy requests which contains the ip of the client you're interested in. You can find that module here http://modules.apache.org/search?id=124 and probably a host of other places. --kip
Re: push_handlers weirdness...
On: Wed, 31 May 2000 17:04:05 EDT Geoffrey Young wrote:
>hi all...
>
> I'm not sure if this is related to some of the get/set handler
>strangeness that I have been seeing lately (as I try to do some weird
>stacked handler acrobatics), or if it's the result of some closure thing
>that I really shouldn't be doing...
>
>package Test::Test;
>use Apache::Constants qw( OK );
>use strict;
>sub handler
>{
>my $r = shift;
>warn "outside..." . $r->current_callback . $r->uri;
>$r->push_handlers(PerlCleanupHandler => sub { warn "inside..." .
>$r->current_callback . $r->uri;
> return OK;});
>return OK;
>}
>1;
>
>anyway, for / => /index.html translation using mod_dir, this PerlInitHandler
>produces:
>
>outside...PerlInitHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
>line 9.
>outside...PerlInitHandler/index.html at
>/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 9.
>
>inside...PerlCleanupHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
>line 10.
>inside...PerlFixupHandler/index.html at
>/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 10.
Hi Geoff,
Isn't this what's expected? The first time through (for "/") you push code
onto the CleanupHandler stack.
Then there's a subrequest (by mod_dir, although I'm just guessing here) to
check for "/index.html", which causes another code ref to be pushed onto
the CleanupHandler stack.
At the completion of the subrequest, the original request is completed,
having two code refs to evaluate once it reaches the Cleanup "phase", one
for the original "/" and one for the "/index.html".
Or am I totally missing your point :)
--kip
Re: handlers
On: Thu, 04 May 2000 18:23:30 -0300 FEITO Nazareno wrote: >Maybe this isn´t the correct mailing list to post this question but i really >need an answer some kind of guide o something like that... >I need to use handlers for my webpages under mod_perl, any tutorial or >something? Check out http://perl.apache.org/guide --kip
Re: how to rewrite to a POST
On: Thu, 27 Apr 2000 09:06:24 EDT "Ken Y. Clark" wrote: >On Wed, 26 Apr 2000, David Hajoglou wrote: > >> so, is it possible to take a GET request and rewrite the uri into a POST >> request and if so how? > >i'm not sure if that's really necessary. you could just put the GET args >into $r->pnotes, perhaps like so: > [ snip ] This approach works, or you could use something like Apache::RequestNotes. However, you still need to deal with file uploads potentially, which I don't believe the RequestNotes does. In my situation, file uploads are important, as is authentication. I check authentication credentials on every request, and redirect to a login page immediately when the check fails. In this case, posted information (including the file upload information) would be lost, which isn't good if the user uploaded a big file. I work around this by doing a simple client-side authentication check (I use cookies to hold a username, so just check to see if it exists), which launches a sub-window allowing the user to authenticate if their cookie has expired. Not the most elegant, but the best I could come up with right now. I also store all the request information in pnotes like RequestNotes. However, I also store a refrence to the file upload information (if any) along with information on where the file contents are located. If there are better solutions out there, I'm all ears! --kip
Re: this might be an obvious one ...
Dave, This has to do with the scoping of that variable, and happens a lot with CGI scripts run under Apache::Registry. There is a nice description of it in "the guide": http://perl.apache.org/guide/obvious.html#my_scoped_variable_in_nested_s --kip On: Wed, 24 Nov 1999 12:47:57 PST "dave_dunstan" wrote: >I'm pretty new to mod_perl so I bet this one is a gimme: > >Variable "$variable" will not stay shared at >/usr/lib/perl5/site_perl/5.005/Apache/MyModule.pm line 295. > >I get a bunch of these when I start httpd - can someone provide more insight >on what's happening here - and maybe how to get rid of these ...?? > >Dave Dunstan >[EMAIL PROTECTED]
Re: Apache::Session and File Upload (Was: Apache::Session hangs script)
Upon further investigation (ok, trial and error...), it seems that using
the multipart form encoding, in conjunction with CGI.pm (I'm using
CGI.pm-2.49) and Apache::Session, causes my test script to hang
at the "op" function within the IPC modules.
In the same test script, if I use the Apache::Request object instead of
the CGI object, the script runs fine, and Apache::Session works fine
(with either form of encoding).
I will be upgrading CGI to the lastest rev to see if that fixes things.
--kip
On: Thu, 21 Oct 1999 19:20:13 EDT
Kip Cranford wrote:
>
>Thanks for the reply, Jeffrey.
>
>Ok, I can understand how leaking session handles would cause a read or
>write lock, or whatever. However, I thought that untieing the session
>hash would release whatever locks the session held -- at the end of the
>simple script I untie the hash.
>
>In fact, the script is so simple I don't see where I could be leaking
>the handles (but just because _I_ can't see where doesn't mean a whole
>lot :)
>
>And finally, to add to my confusion, I can take the test script, change
>the form encoding from multipart to x-www-form-urlencoded, and have it
>work fine. Change it back to multipart, and it hangs. Any idea there??
>
>Thanks for your attention,
>
>--kip
>
>p.s. I'm including the test script at the end of this message -- there's
>probably something obviously wrong that I just can't see...
>
>
>>
>>The problem is that you are leaking session handles. For
>>Apache::Session to work, there must be zero references to the session
>>hash at the end of the request.
>>
>>-jwb
>>--
>>Jeffrey W. Baker * [EMAIL PROTECTED]
>>Critical Path, Inc. * we handle the world's email * www.cp.net
>>415.808.8807
>>
>
>
>
>Test Script
>
>
>use strict;
>use Apache ();
>use Apache::Constants qw( :common );
>use Apache::Session::DBI;
>use CGI();
>
>sub handler {
> my $r = shift;
>
> $r->send_http_header("text/html");
>
> my $session_id = CGI::param('session') || undef;
>
> my %session;
> my $opts = {
> DataSource => 'dbi:mysql:sessions',
> UserName=> 'nobody',
> Password=> '',
> };
>
> tie %session, 'Apache::Session::DBI', $session_id, $opts;
>
> my $file = CGI::param('upload');
> if ($file) {
> $session{'file'} = $file;
> }
>
> print<<__EOS__;
>
>Apache::Session Test Script
>Session ID number is: $session{_session_id}
>Storing file: $file
>
>
>http://xxx/secure" enctype="multipart/form-data" method="post">
>
> Type in your name here:
>
>
>
>
>__EOS__
>print "untieing the session...";
>untie %session;
>}
>
>1;
>
>===
>End Test Script
>===
Re: Apache::Session and File Upload (Was: Apache::Session hangs script)
Thanks for the reply, Jeffrey.
Ok, I can understand how leaking session handles would cause a read or
write lock, or whatever. However, I thought that untieing the session
hash would release whatever locks the session held -- at the end of the
simple script I untie the hash.
In fact, the script is so simple I don't see where I could be leaking
the handles (but just because _I_ can't see where doesn't mean a whole
lot :)
And finally, to add to my confusion, I can take the test script, change
the form encoding from multipart to x-www-form-urlencoded, and have it
work fine. Change it back to multipart, and it hangs. Any idea there??
Thanks for your attention,
--kip
p.s. I'm including the test script at the end of this message -- there's
probably something obviously wrong that I just can't see...
>
>The problem is that you are leaking session handles. For
>Apache::Session to work, there must be zero references to the session
>hash at the end of the request.
>
>-jwb
>--
>Jeffrey W. Baker * [EMAIL PROTECTED]
>Critical Path, Inc. * we handle the world's email * www.cp.net
>415.808.8807
>
Test Script
use strict;
use Apache ();
use Apache::Constants qw( :common );
use Apache::Session::DBI;
use CGI();
sub handler {
my $r = shift;
$r->send_http_header("text/html");
my $session_id = CGI::param('session') || undef;
my %session;
my $opts = {
DataSource => 'dbi:mysql:sessions',
UserName=> 'nobody',
Password=> '',
};
tie %session, 'Apache::Session::DBI', $session_id, $opts;
my $file = CGI::param('upload');
if ($file) {
$session{'file'} = $file;
}
print<<__EOS__;
Apache::Session Test Script
Session ID number is: $session{_session_id}
Storing file: $file
http://xxx/secure" enctype="multipart/form-data" method="post">
Type in your name here:
__EOS__
print "untieing the session...";
untie %session;
}
1;
===
End Test Script
===
Apache::Session and File Upload (Was: Apache::Session hangs script)
Again, I'm using mod_perl 1.21, apache 1.3.9, Apache::Session 1.03, on a
RedHat 6 linux system with perl 5.005_03, and am using Netscape Comm.
4.51 as my browser.
The problem now seems to be Apache::Session and file uploads. My
handler is providing a simple file upload interface, and I'm using
Apache::Session to keep track of filenames, content types, sizes, etc.
Using a very simple script, in which I store only a single scalar
variable in my session, and using the "multipart/form-data" encoding
type on my form, I can get the script to hang every time. It _always_
hangs in the same place in the "op" function:
DB<1> IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:90):
90: croak 'Bad arg count' if @_ % 3;
DB<1> IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:91):
91: my $data = pack("s*",@_);
DB<1> IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:92):
92: semop($$self,$data);
This happens whether I use Apache::Session::DBI or ::File...
If I use the older encoding type on the form, everything works fine.
I'm using CGI.pm, but right now only for the param() function. The html
form was specified directly in a here document.
Has anyone seen this behavior before? Any help would be GREATLY
apprecitated!!
Thanks,
--kip
Apache::Session hangs script
I'm using Apache/1.3.9 (Unix), mod_perl/1.21, Apache-Session-1.03, with
MySQL 3.22.25. I'm using the the Apache::Session::DBI module with MySQL
to provide some simple session management. I'm running the script as a
PerlHandler...
I'm storing the session ID as a hidden variable, which I retrieve on
subsequent calls to the script, and use it to re-open the session object
as described in the Apache::Session doc.
1 or 2 calls _after_ the intial invocation of the script, my browser
hangs. Using the debugger, I've found where it seems to get hung up --
see below.
Is this some sort of lock blocking, or stale lock or something? Any
help would be appreciated.
Thanks,
--kip
=-=-=-=-=-=-=-= Debugging Output =-=-=-=-=-=-=-=
DB<1> s
Apache::Session::SysVSemaphoreLocker::acquire_read_lock(/usr/lib/perl5/site_perl/5.005/Apache/Session/SysVSemaphoreLocker.pm:50):
50: $self->{sem}->op($self->{read_sem} + $self->{nsems}/2, 0,
SEM_UNDO,
51: $self->{read_sem},1,
SEM_UNDO);
DB<1> s
IPC::SysV::SEM_UNDO(/usr/lib/perl5/5.00503/IPC/SysV.pm:65535):
65535:
DB<1> s
IPC::SysV::SEM_UNDO(/usr/lib/perl5/5.00503/IPC/SysV.pm:65535):
65535:
DB<1> s
IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:88):
88: @_ >= 4 || croak '$sem->op( OPLIST )';
DB<1> s
IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:89):
89: my $self = shift;
DB<1> s
IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:90):
90: croak 'Bad arg count' if @_ % 3;
DB<1> s
IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:91):
91: my $data = pack("s*",@_);
DB<1> s
IPC::Semaphore::op(/usr/lib/perl5/5.00503/IPC/Semaphore.pm:92):
92: semop($$self,$data);
DB<1> s
/\
|
|
---|
Hangs Here...
