>
> 3. This is the core dump trace: (if you get a core dump):
>
> I tried but I can't catch any (I don't know and didn't manage to find out
which
> directory has to be writeable for the apache2 process under Embperl).
>
Please try to start your httpd under gdb:
gdb /path/to/httpd
set args -X -f
Hi!
1. Problem Description:
My apache child crash with a segfault when I call a page which generates a graph
using the perl module GD::Graph.
My system specs are:
Fedora Core 1
httpd-2.0.47 (from fedora, also tried with self-compiled 2.0.48)
mod_perl-1.99_11 (the final version, self-compiled)
Marc Slagle wrote:
[...]
If you need any more information, please let us know.
I went through the pain of installing all these prerequisited just to run your
handlers, but it works just fine for me. I've tried to match the perl-5.8.0
build and the only difference I think is that I used the latest
Swen Schillig wrote:
Thanks for the detailed report, Swen. Frankly I'm puzzled about the lack of
errors. Before we go into low level tracing, I'd like to check something:
[...]
perl -V
[...]
optimize='-O3',
From gcc(1):
-O3 Optimize yet more. -O3 turns on all optimizations specified
Matthew Darwin wrote:
After extensive playing around with this (inside mod_perl and out), I
have come up with two observations:
1) doing regexes on UTF-8 characters split across buckets in an output
filter seems to be not a problem. All my regexes are against ASCII
characters.
Good. But could
Tom Conway wrote:
I'm just starting with mod_perl. I converted my cgi scripts for mod_perl
usage. They work fine as plain cgi. When i go from one screen to another
via submit or link, or just refresh a couple of times my data
disappears. No errors, just a blank form. I have no idea what is wrong
Andrew Green wrote:
On Tue, 11 Nov 2003 19:01:57 + (GMT), Ged Haywood wrote:
Perl 5.8.1 is not binary compatible with 5.8.0, which was not the
intention and 5.8.2 will return to compatibility, hence my comment.
Ah, I see. Sorry for the misunderstanding.
And 5.8.2 is out for almost a week no
Perrin Harkins wrote on 11/11/2003 1:11 PM:
> (Sorry, I didn't see your reply until now.)
>
> On Thu, 2003-11-06 at 19:04, Joachim Feise wrote:
>
>>> Are you usng PerlFreshRestart?
>>
>>Yes.
>
>
> That's the reason you're having this problem. It's probably a bad idea
> to use that. What it d
I'm just starting with mod_perl. I converted my cgi scripts for mod_perl
usage. They work fine as plain cgi. When i go from one screen to another via
submit or link, or just refresh a couple of times my data disappears. No
errors, just a blank form. I have no idea what is wrong.
I've verified a
On Mon, 2003-11-10 at 22:07, Anatoly Vorobey wrote:
> In fact, some of the stuff I'm
> preloading aren't .pm modules, they're .pl libraries I want to
> "require" rather than "use".
Be careful with the .pl libs. If they export functions (i.e. do not
have their own package namepsace), the function
Bruce Langlois <[EMAIL PROTECTED]> writes:
> I have encountered what I consider a bug in the 'param' method
> of Apache::Request in mod_perl 1. The method returns a
> list of parameters, or a '0' if no parameters are found.
[...]
> The documentation does not specify what the actual return shoul
(Sorry, I didn't see your reply until now.)
On Thu, 2003-11-06 at 19:04, Joachim Feise wrote:
> > Are you usng PerlFreshRestart?
>
> Yes.
That's the reason you're having this problem. It's probably a bad idea
to use that. What it does is empty %INC so that a "use CGI" will
recompile the modul
I don't have full control over my installation because
I'm hosting with someone else. But I was able to
remove mod_php and it worked!!
Since I'm not using php this works for me.
Thanks Perrin you are awesome!
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Tue, 2003-11-11 at 11:36, Global
I have encountered what I consider a bug in the 'param' method
of Apache::Request in mod_perl 1. The method returns a
list of parameters, or a '0' if no parameters are found. This
makes the following code create a bogus param entry:
%input = map {$_ => join("\t", $apr->param($_))} $apr->param;
Original Message
Subject:Re: NTLM mod based on Apache::Session
Date: Tue, 11 Nov 2003 17:50:13 +
From: Leo Lapworth <[EMAIL PROTECTED]>
Reply-To: Leo Lapworth <[EMAIL PROTECTED]>
To: Stefano Ciancio <[EMAIL PROTECTED]>
Hi Stefano,
I think you p
Original Message
Subject:NTLM mod based on Apache::Session
Date: Tue, 11 Nov 2003 16:21:13 +0100
From: Stefano Ciancio <[EMAIL PROTECTED]>
Organization: Italia On Line
To: Shannon Eric Peevey <[EMAIL PROTECTED]>, Leo Lapworth <[EMAIL PROTECTED]>
Hi Leo,
Hi Sh
On Tue, 2003-11-11 at 13:50, Douglas Hunter wrote:
> I don't know if it qualifies as a bright idea, but could you implement a
> filter class using tie?
Thanks for the suggestion. That's a neat trick, but it feels like
overkill for this purpose. I think I'm going to end up just turning off
warni
On Tue, 2003-11-11 at 13:16, Graeme Fowler wrote:
> This is precisely the approach I'm using at the moment; however I'm
> looking into reload speed and this will not scale far enough for me. I
> could be looking at tens of thousands of virtual hosts per server in a
> load balanced environment, so t
After extensive playing around with this (inside mod_perl and out), I
have come up with two observations:
1) doing regexes on UTF-8 characters split across buckets in an output
filter seems to be not a problem. All my regexes are against ASCII
characters.
2) mod_perl seems to get confused whe
On Tue, 2003-11-11 at 11:36, Global Junk wrote:
> Does anyone have any ideas or links to help with
> Mod_Perl and MySQL running together?
It may be PHP that is causing the problem here.
See this warning in the docs:
http://perl.apache.org/docs/1.0/guide/troubleshooting.html#_exit_signal_Segmentat
Hi Graeme -
> my ($vhostname,$vhostuser,$vhosthomedir,$vhostip) = split $_, / /;
I think you mean:
my ($vhostname,$vhostuser,$vhosthomedir,$vhostip) = split / /, $_;
I'd suggest extracting the section code into a standalone script to
verify it works, then pop it back into httpd.conf.
L
On Tue, 11 Nov 2003 19:01:57 + (GMT), Ged Haywood wrote:
> Perl 5.8.1 is not binary compatible with 5.8.0, which was not the
> intention and 5.8.2 will return to compatibility, hence my comment.
Ah, I see. Sorry for the misunderstanding.
> ...your own bugs will be much more troublesome than
Hi there,
On Tue, 11 Nov 2003, Andrew Green wrote:
> On Tue, 11 Nov 2003 18:19:31 + (GMT), Ged Haywood wrote:
>
> > If you're using 5.8.0 right now you're probably best advised
> > to wait for Perl 5.8.2, as 5.8.1 has a few issues - but it does work
> > OK.
>
> Really? Is it ill-advised to
Perrin Harkins wrote:
So, the question is, what's an elegant way to eliminate this warning? I
could modify Apache::DBI to do it (although filtering a specific
warning, as opposed to simply turning them all off temporarilly, could
be a pain). I could install a WARN handler. Ick. Any other brigh
I've been using mysql+mod_perl for years. You should check that you
aren't connecting to the database in the apache startup phase and then
using the same connection in a handler.
Ged Haywood wrote:
Hi there,
On Tue, 11 Nov 2003, Global Junk wrote:
I'm running Linux Apache/1.3.26 (Unix) mod_p
On Tue, 11 Nov 2003 18:19:31 + (GMT), Ged Haywood wrote:
> If you're using 5.8.0 right now you're probably best advised
> to wait for Perl 5.8.2, as 5.8.1 has a few issues - but it does work
> OK.
Really? Is it ill-advised to use 5.8.1 in a production mod_perl
environment? I'm in the proce
On Tue, 2003-11-11 at 18:34, Chris Grau wrote:
> Is there a particular reason you've chosen to generate many VirtualHost
> directives in your configuration file? Have you tried mod_vhost_alias?
> It sounds like a perfect fit for you.
Yes - namely that this will be a migration from an existing env
On Tue, Nov 11, 2003 at 06:16:34PM +, Graeme Fowler wrote:
> Hi
>
> On Tue, 2003-11-11 at 17:43, Cees Hek wrote:
[snip]
> > Flip your strategy around, and have a plain old perl script
> > generate the proper Apache config files for your VirtualHosts
> > and place those config files in a direct
Hi there,
On Tue, 11 Nov 2003, Global Junk wrote:
> I'm running Linux Apache/1.3.26 (Unix) mod_perl/1.26
> PHP/4.2.3 and MySQL.
> I'm trying to write a simple web (perl) application
> that accesses a mysql database. I'm using DBI().
> When I access the site under normal Perl it works.
> When
Hi
On Tue, 2003-11-11 at 17:43, Cees Hek wrote:
> I could very well be wrong, but I have a feeling that the support in
> mod_perl2 is not fully completed yet.
Ah. I was beginning to think as much. I really don't want to spend a
huge amount of time with the Apache 1.3.x + mod_perl 1.x combination
Quoting Graeme Fowler <[EMAIL PROTECTED]>:
> I've searched, and searched, for a recipe and/or method for this; I can't
> find
> one that works :(
>
> Am using a home-rolled Apache 2.0.48 and mod_perl 1.99_10 setup.
I could very well be wrong, but I have a feeling that the support in
mod_perl2 i
On Tue, 11 Nov 2003, Thomas Schindl wrote:
> Why not using conf.d all conf-files from there get loaded automatically?
Only if the "Include conf.d/*.conf" statement still exists. I'm trying to move
away from RedHat-derived semantics, because the system may have to run on a
number of different pla
Hi,
Why not using conf.d all conf-files from there get loaded automatically?
Tom
On Tue, 2003-11-11 at 17:37, Graeme Fowler wrote:
> Howdy
>
> I've searched, and searched, for a recipe and/or method for this; I can't find
> one that works :(
>
> Am using a home-rolled Apache 2.0.48 and mod_pe
Howdy
I've searched, and searched, for a recipe and/or method for this; I can't find
one that works :(
Am using a home-rolled Apache 2.0.48 and mod_perl 1.99_10 setup.
Given a file containing lines of the form:
lweb1.graemef.net root /root/public_html 192.168.100.211
and an "Include" statemen
I'm running Linux Apache/1.3.26 (Unix) mod_perl/1.26
PHP/4.2.3 and MySQL.
I'm trying to write a simple web (perl) application
that accesses a mysql database. I'm using DBI().
When I access the site under normal Perl it works.
When I access the site under Mod_Perl I get:
child pid 20524 exit s
At 09:55 PM 11/10/2003 -0500, Perrin Harkins wrote:
>On Mon, 2003-11-10 at 21:31, Stas Bekman wrote:
>> Thanks Perrin for this comparison numbers, but I think you didn't provide
>> enough build information. Default build opts vary from release to release and
>> from OS to OS, you really need to s
> I don't have a test to reproduce the segfault, so I'm just shooting in the
> dark based on the core trace that you've kindly provided. Please revert the
> previous patch and try the new one:
One more bit of information: we were using an older version of
Apache::Request, but upgraded it to the
> I don't have a test to reproduce the segfault, so I'm just shooting in the
> dark based on the core trace that you've kindly provided. Please revert the
> previous patch and try the new one:
We tried the new patch, but can still get the segfault. We wrote 3
modules that can reproduce the segfa
Ok, sorry for the inconvenience.
Here is the requested information.
-8<-- Start Bug Report 8<--
1. Problem Description:
Errors with make test
2. Used Components and their Configuration:
*** mod_perl version 1.9911
*** using lib/Apache/BuildConfig.pm
*
Swen Schillig wrote:
Hi *
After downloading the newest versions of mp2, libapreq2
At the moment you don't need libapreq2 to run the test suite. Though it's a
good idea to add some for the next release.
I was able to compile to compile everything but the the test-suits showed
some errors.
To star
> > should building a DSO in mod_perl 1.x versions just be avoided?
>
> I think so, and so I think does Randal. This was discussed briefly
> here not long ago in a couple of threads, check the archives.
But note, that in DSO version graceful restart works perfectly (the
clients does not notice a
Hi *
After downloading the newest versions of mp2, libapreq2
I was able to compile to compile everything but the the test-suits showed
some errors.
I don't know if I'm doing something very stupid here but maybe one
of you experienced the same and can help me out with some advice.
Failed Test
42 matches
Mail list logo
