mance efficiency boosts in your modperl handlers
with sealed.pm, (but avoid reentrancy/recursion for those subs, or you may
segfault).
--
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
954.253.3732
On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr
wrote:
> On May 29, 2016 01:02, "Jie Gao" wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty i
On May 29, 2016 01:02, "Jie Gao" wrote:
>
> Hi All
>
> I wonder if anybody is looking at this issue. At the moment, the build
cores even at the end of generating a Makefile.
>
> If not, I would like to get my hands dirty in an attmpt to get the ball
rolling. Any help on how to get a handle on the
/usr/local/httpd-2.4.20/bin/httpd -core
/usr/local/src/mod_perl-2.0/t/core.15035
-Jie
* Jie Gao wrote:
> Date: Sun, 29 May 2016 16:02:17 +1000
> From: Jie Gao
> To: d...@perl.apache.org, modperl@perl.apache.org
> CC: William A Rowe Jr
> Subject: Re: New segfault with 2.4.20
W. Rowe Jr would be much appreciated.
Regards,
Jie
* William A Rowe Jr wrote:
> Date: Thu, 19 May 2016 11:23:33 -0500
> From: William A Rowe Jr
> To: httpd , modperl@perl.apache.org
> Subject: Re: New segfault with 2.4.20 with mod_perl
>
> Re-sending to include the correct pe
Re-sending to include the correct perl.a.o dev list.
On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr
wrote:
> The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
>
> First, the handler is registered using
>
> PerlProcessConnectionHandler TestProtocol::pseudo_http
>
> so it
> Hello,
>
> simply adding $[
> to /etc/apache2/apache2.conf (or PerlPostConfigRequire a file
> containing $[) causes apache to segfault (trace below).
>
> Strangely this happens _only_ if mod_php is also loaded!
Is PHP acting like a Poltergeist? (Sorry, I co
Hello,
simply adding $[
to /etc/apache2/apache2.conf (or PerlPostConfigRequire a file
containing $[) causes apache to segfault (trace below).
Strangely this happens _only_ if mod_php is also loaded!
No sane person cares about $[, but it's not uncommon to
PerlPostConfigRequire som
> > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> > cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'
> >
> > And BTW is there any existing RPM for RHEL that is dynamic build already?
>
xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> > cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
> > -fstack-protector'
> >
> > And BTW is there any existing RPM for RHEL that is dynamic build already?
> >
> >
ynamic build already?
> Date: Thu, 23 Aug 2012 09:17:48 +0300
> From: d...@debian.org
> To: modperl@perl.apache.org
> Subject: Re: mod_perl always segfault on thread creation
>
> -=| hack bear, 22.08.2012 16:16:33 -0700 |=-
> >
> > I'm doing a dynamic build (the default
L/usr/local/lib
-fstack-protector'
And BTW is there any existing RPM for RHEL that is dynamic build already?
> Date: Thu, 23 Aug 2012 09:17:48 +0300
> From: d...@debian.org
> To: modperl@perl.apache.org
> Subject: Re: mod_perl always segfault on thread creation
>
> -=| hack be
-=| hack bear, 22.08.2012 16:16:33 -0700 |=-
>
> I'm doing a dynamic build (the default setting I believe.) here are the ldd
> results (that's how we can tell, right?)
To me this seems like a static build. Yes, it links dynamicly to
system libraries, but the perl library is staticly linked. Com
o.0 (0x7fbe6e19f000)
libc.so.6 => /lib64/libc.so.6 (0x7fbe6de0e000)
/lib64/ld-linux-x86-64.so.2 (0x0039be80)
libfreebl3.so => /lib64/libfreebl3.so (0x7fbe6dbac000)
> Date: Wed, 22 Aug 2012 17:11:32 -0600
> From: dh...@ucar.edu
> To: hackingb...@hotmail.
ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -m64 -mtune=nocona',
Then I install the perl build, build mod_perl and install. Verify I'm using the
new versions in apache.
='-D_REENTRANT -D_GNU_SOURCE -fPIC -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fPIC -m64 -mtune=nocona',
Then I install the perl build, build mod_perl and install. Verify I'm using the
new versions in apache. But still t
tion fault)
We can tell that apache starts up perl successfully the first time by
running strace. The segfault can be traced to one line in Carp.pm:
%<
# Transform an argument to a function into a string.
sub format_ar
.com]
Sent: Tuesday, August 21, 2012 2:06 AM
To: modperl@perl.apache.org
Subject: mod_perl always segfault on thread creation
hi,
This is totally frustrating. My mod_perl script always causes segmentation
fault when it tries to create a thread. I searched the Web and this forum, but
there i
rver.html).
httpd -X
(segmentation fault)
We can tell that apache starts up perl successfully the first time by running
strace. The segfault can be traced to one line in Carp.pm:
%<
# Transform an argument to a
hi,
This is totally frustrating. My mod_perl script always causes segmentation
fault when it tries to create a thread. I searched the Web and this forum, but
there is still no definitive answers. My perl and mod_perl are of pretty recent
versions and I check for the inclusion of useithreads co
perl startup.
(perl starts up twice when apache is started, as explained in
http://perl.apache.org/docs/2.0/user/handlers/server.html).
httpd -X
(segmentation fault)
We can tell that apache starts up perl successfully the first time by
running strace. The segfault can be traced to one li
Hello Fred,
Thank you for pointing out the upcoming release. Unfortunately, after
checking out and installing the latest version from SVN, I'm still
seeing the same issue. Apache still segfault while trying to load any
Perl module that directly or indirectly use Carp. According to &quo
gmentation faults) with same
> httpd.conf which worked previously.
>
> As far as I can tell, the segfault seems to be triggered while trying to
> load any Perl module using either PerlModule directive or in block in
> httpd.conf that directly or indirectly use Carp, or even just try to load
&
with same httpd.conf which worked previously.
As far as I can tell, the segfault seems to be triggered while trying to
load any Perl module using either PerlModule directive or in
block in httpd.conf that directly or indirectly use Carp, or even just
try to load Carp itself. Strace shows that t
On Tuesday, 06 December 2011 17:40:14 Merlyn Kline wrote:
> To REPRODUCE the problem, you need a Broken.pm module like this:
>
> package Broken;
> my $Testout;
> create(); sub create { # Insert "{#" at the start of this line and the
> segfault goes away ope
On Wednesday, 07 December 2011 02:37:19 gAzZaLi wrote:
> Another option is to 'use Test::More' explicitly:
> (Do note that I have managed to segfault this)
>
> use Apache::Test qw(:withtestmore);
> use Test::More;
As of Apache::Test 1.35++ this is wrong. Sorry about
urn (
$Test->ok( "$first_num" > "$second_num", $dsc ) ||
$Test->diag(" $first_num is not bigger than $second_num ")
);
}
1;
### End Broken.pm ###
Another option is to 'use Test::More' explicitly:
(Do note tha
discovered that simply "use"ing Test::More in a mod_perl script causes
my apache to segfault. I originally reported this to the author of Test::More
(see https://rt.cpan.org/Public/Bug/Display.html?id=69687) but now believe the
problem to have wider scope. By progressively removing co
<-- Start Bug Report 8<--
1. Problem Description:
Apache segfault when using mod_perl.
Seems to occures when a process send more than 32kB of data.
2. Used Components and their Configuration:
*** mod_perl version 2.05
*** using /tmp/libapache2-mod-perl2-2.0
After experimenting around, the reason is the global directive
I use (perfectly valid)
ErrorLog syslog:local6
that crashes
#ifdef MP_TRACE
/* httpd core open_logs handler re-opens s->error_log, which might
* change, even though it still points to the same physical file
* (.e.g on w
Same problem on 2.0.5 and gentoo 2010
That's how I run it
r -D SSL -D SSL_DEFAULT_VHOST -D DEFAULT_VHOST -D INFO -D DAV -D DAV_FS
-D CACHE -D MEM_CACHE -D PHP5 -D PERL_VHOST -D PYTHON -D STATUS -D PROXY
-D PROXY_HTML -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -E
/var/log/apache2/startuperror.
We recently ran into the problem documented here:
http://www.mail-archive.com/modperl@perl.apache.org/msg00947.html
http://tech.groups.yahoo.com/group/modperl/messages/55410?threaded=1&m=e&var=1&tidx=1
We ended up finding the offending global storage that was holding on
the Apache::Table
On 03/19/2011 06:11 PM, Fred Moyer wrote:
> Have you tried 2.0.5?
>
nope, was on gentoo 2008 which I tried to keep but looks like I must
upgrade so I check out 2011 distro now and see whether it persists
-- tony
> On Sat, Mar 19, 2011 at 9:15 AM, A. Przygienda wrote:
>> -8<---
Have you tried 2.0.5?
On Sat, Mar 19, 2011 at 9:15 AM, A. Przygienda wrote:
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
> Crash gentoo apache2 start. core dump below, think tries to dup
> a 0 file pointer
>
>
> [DESCRIBE THE PROBLEM HERE]
>
-8<-- Start Bug Report 8<--
1. Problem Description:
Crash gentoo apache2 start. core dump below, think tries to dup
a 0 file pointer
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** mod_perl version 2.04
*** using
/u
essor
> > I could find in my perl directories.
>
> The first thing I'd suggest is making sure you have the latest
> version. There's some stuff about recent fixes for segfaults in the
> changes file.
Confirmed. Class::XSAccessor 0.11 (latest CPAN version atm) fixes my
segfault problems.
Thanks Perrin,
--
Cosimo
gest is making sure you have the latest
version. There's some stuff about recent fixes for segfaults in the
changes file.
> Next thing I'm going to try is to selectively remove bits from
> my startup.pl to pinpoint areas of the code that might
> lead to this segfault.
Not a ba
lass uses Class::XSAccessor through
Class::Accessor::Grouped. That's the only use of Class::XSAccessor
I could find in my perl directories.
Next thing I'm going to try is to selectively remove bits from
my startup.pl to pinpoint areas of the code that might
lead to this segfault.
In the meantim
Hi all,
I'm still trying to track down this weird segfault
problem on Apache startup. I had originally targetet dbi-users@
because it initially seemed to be DBI-related. Was trying to get
some feedback, "has anyone ever seen this?" type of question.
Now I have a stack backtr
>>> On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
>>> > I suggest the code shift items off the main array, like perl does,
>>> > but also push those items onto a new temp array.
Find attached a patch that does the above (perhaps naively), passes a
make test and fixes the reported problems for m
On Wed, Jun 30, 2010 at 16:37, Tim Bunce wrote:
> On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote:
>> On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
>> > I suggest the code shift items off the main array, like perl does,
>> > but also push those items onto a new temp array.
> I pr
On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote:
> On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
> > On Tue, Jun 29, 2010 at 09:50:00PM -0700, Fred Moyer wrote:
> >> I think getting rid of the segfault is a good thing. But if the main
> >> problem is i
On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
> On Tue, Jun 29, 2010 at 09:50:00PM -0700, Fred Moyer wrote:
>> I think getting rid of the segfault is a good thing. But if the main
>> problem is issues with NYTProf, then it seems like this change won't
>> solve the cor
we wont run any newly defined subs... But at least we wont
> > segfault/crap out.
> >
> > Thoughts?
>
> I think getting rid of the segfault is a good thing. But if the main
> problem is issues with NYTProf, then it seems like this change won't
> solve the core
but I can see not wanting to
> break other things that use modperl_perl_call_use. Maybe, maybe not.
> Thoughts?
ModPerl::RegistryCooker appears to use the special_list calls.
http://perl.apache.org/docs/2.0/api/ModPerl/Global.html
So the fix could introduce some breakage into deployments w
Thoughts?
Another option would be to copy/local() the array in
modpler_perl_call_list. Of course that still wont get it "right"
because we wont run any newly defined subs... But at least we wont
segfault/crap out.
Thoughts?
--- modperl_util.c.orig 2010-06-28 10:58:53.535686254 -0600
On Thu, May 7, 2009 at 4:41 PM, Brian Hirt wrote:
> I just built up a new mod_perl1.30 with apache 1.3.41 and started seeing
> segfaults in my logs. I ended up tracking the problem down to
> http://svn.apache.org/viewvc?view=rev&revision=555908
>
> It looks like a fix was committed almost 2 year
I just built up a new mod_perl1.30 with apache 1.3.41 and started
seeing segfaults in my logs. I ended up tracking the problem down to http://svn.apache.org/viewvc?view=rev&revision=555908
It looks like a fix was committed almost 2 years ago.
So my questions are these. Is a 1.31 ever going
> On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric
> > When I say that Test::Builder/Test::More/etc. are tightly
> > coupled, I'm talking really entwined. In some cases, we have
created a
> > class with a bunch of test-related methods that look through the
symbol
> > table and find methods that =~ m
On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric <[EMAIL PROTECTED]> wrote:
> When I say that Test::Builder/Test::More/etc. are tightly coupled, I'm
> talking really entwined. In some cases, we have created a class with a
> bunch of test-related methods that look through the symbol table and
> find meth
ginal Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Perrin Harkins
> Sent: Thursday, September 04, 2008 6:36 PM
> To: Berg, Eric
> Cc: modperl@perl.apache.org
> Subject: Re: mod_perl2 + ModPerl::RegistryPrefork +
> Test::Builder = segfault
&
On Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric <[EMAIL PROTECTED]> wrote:
> Many of our core modules contain test methods that are executed during
> our CVS checkin process as regression tests, so we'd have to completely
> redo our regression testing architecture to decouple Test::Builder from
> our co
g under ModPerl::RegistryPrefork
causes it to segfault on a very regular basis.
Here's the message I posted on CPAN Forum for Test::Simple:
>>>>>>>>>>>>>>>
Recently, during the process of porting all my apache 1.3/mod_perl 1.x
CGI's running under ModPer
I posted this a little while ago, and was hoping that some of you
C-oriented folks could take a look at this stack trace and see if
anything jumps out at you that would indicate why I'm consistently
getting segmentation faults (11) when forking in a CGI running under
ModPerl::RegistryPrefork.
Than
> I don't know the details, but there is something about the way
> PerlModule works in mod_perl 1 that causes it to load the module again
> when apache restarts at startup (it runs yours conf file twice when
> you start, as documented). Using an explicit use() puts an entry in
> %INC and fixes the
On Wed, Jul 2, 2008 at 5:12 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> No more errors there either! :)
Great!
> I don't know anything about the internals but to me the mod_perl source looks
> like PerlModule is using "require" instead of "use" to load modules. I guess
> that is making the dif
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> > How are you loading this? With a PerlModule call? Can you try
> > loading it from a Perl section like this?
> >
> > use MyModule;
> >
> Wow, it seems that this fixes the problem!
> Do you have any ide
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> How are you loading this? With a PerlModule call? Can you try
> loading it from a Perl section like this?
>
> use MyModule;
>
Wow, it seems that this fixes the problem! At least with my minimal application.
Here's the debug output which looks qu
On Tue, Jul 1, 2008 at 10:08 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> On server start:
>
> 20097 Apache::DBI skipping connection during server startup, read the docu !!
> 20097 Apache::DBI push PerlCleanupHandler
> 20097 Apache::DBI need ping: yes
> 20097 Apache::DBI new
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> Yes, but what does it tell you on the first connection AFTER startup?
> It should say whether it's making a new connection or not.
Here's the complete debug output which suggests that the connection during
startup is reused for the first request.
On s
On Tue, Jul 1, 2008 at 9:56 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> Yes, I'm using the latest 1.07 release. I already had the debug flag on and
> it's
> correctly telling me that it's "skipping connection during server startup".
Yes, but what does it tell you on the first connection AFTER
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> Ok. First, check that you're on the latest version. Then, turn on
> the debug flag and see if it thinks it is reusing the startup
> connection or not.
Yes, I'm using the latest 1.07 release. I already had the debug flag on and it's
correctly telling
On Tue, Jul 1, 2008 at 3:42 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> Removing Apache::DBI makes the errors go away.
Ok. First, check that you're on the latest version. Then, turn on
the debug flag and see if it thinks it is reusing the startup
connection or not.
- Perrin
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> On a closer look, you're not. You are keeping around your $foo
> closure variable in handler(), as well as putting it in a global.
> It's not obvious why that causes this problem. If you want to
> determine whether Apache::DBI is malfunctioning for yo
Stephen Howard wrote:
1. Problem Description:
I have an intermittent segfault with one particular ResponseHandler.
The segfault, when it occurs, is triggered by calling $r->content_type
in a lightly modified CGI::Simple (I made changes to it as it wasn't
playing well with m
On Mon, Jun 30, 2008 at 1:40 PM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> Could you please show me the exact line in my example in which I put the
> database handle in a
> global during startup?
On a closer look, you're not. You are keeping around your $foo
closure variable in handler(), as wel
On 30.06.2008, at 17:10, Perrin Harkins wrote:
It's not Apache::DBI that's caching it -- you're caching it. Don't
put a database handle in a global before you fork. It will stay, and
there's nothing Apache::DBI can do about it.
Could you please show me the exact line in my example in which I
Tobias Kremer wrote:
> Quoting Michael Peters <[EMAIL PROTECTED]>:
>> Why are you storing the DB handle in a global variable?
>> If you do that then Apache::DBI can't help you if the connection goes away.
>
> To make this variable available to all Mason components.
Then use a method to do this,
On Mon, Jun 30, 2008 at 11:02 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> According to the docs Apache::DBI
> should automatically avoid caching this connection.
It's not Apache::DBI that's caching it -- you're caching it. Don't
put a database handle in a global before you fork. It will stay,
Quoting Michael Peters <[EMAIL PROTECTED]>:
> Tobias Kremer wrote:
> > use vars qw( $dbh $thefoo );
> Why are you storing the DB handle in a global variable?
> If you do that then Apache::DBI can't help you if the connection goes away.
To make this variable available to all Mason components. Theor
Tobias Kremer wrote:
> use vars qw( $dbh $thefoo );
Why are you storing the DB handle in a global variable?
If you do that then Apache::DBI can't help you if the connection goes away.
--
Michael Peters
Plus Three, LP
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> I don't see anything in this code, but you're not really showing us
> much here. I think you'll need to try commenting out parts of it
> until you find which part breaks it. I'd start with that
> selectall_arrayref that you store.
I can reproduce the
On Mon, Jun 30, 2008 at 10:54:20AM +0200, Tobias Kremer wrote:
> Any other ideas? Thanks!
It could be that your query(result) is too large for the
'max_allowed_packet' setting. The mysql-client that is connected to your
process will then silently die, giving the 'Lost mysql...' error as
result.
On Mon, Jun 30, 2008 at 9:28 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> Ok, I narrowed it down to the database connection initiated during server
> startup. As soon as I remove it the errors vanish completely.
Good, that's major progress.
> Here are some snippets to illustrate what I'm doing:
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> > We never fork and I thought that Apache::DBI takes care of checking if a
> > connection went stale by utilizing DBI's/DBD::mysql's ping() method?
> It does, but it can't stop
On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> We never fork and I thought that Apache::DBI takes care of checking if a
> connection went stale by utilizing DBI's/DBD::mysql's ping() method?
It does, but it can't stop you from doing things like putting a
database handl
Quoting Perrin Harkins <[EMAIL PROTECTED]>:
> On Fri, Jun 27, 2008 at 5:51 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> > Now if I could just get rid of those annoying random "Commands out of sync"
> and
> > "Lost connection to MySQL server during query" errors that happen once in a
> > while ...
On Fri, Jun 27, 2008 at 5:51 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:
> Now if I could just get rid of those annoying random "Commands out of sync"
> and
> "Lost connection to MySQL server during query" errors that happen once in a
> while ...
Those generally mean that you timed out (set MySQ
On AIX 5.2 I am using Perl 5.8.0, MySQL 5.0.51a, Apache 2.2.28, mod_perl
2.04, DBI 1.604 and DBD 4.0007 and it all works good.
--Brian
-Original Message-
From: Tobias Kremer [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2008 5:51 AM
To: modperl@perl.apache.org
Subject: Re: Segfault
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> On 25.06.2008, at 20:58, Amiri Barksdale wrote:
> > I had big trouble with DBD::mysql 4.007. I didn't get rid of my
> > segfault problem running mod_perl 1.31 until I went back to 4.004.
>
> Thanx. It really looks
1. Problem Description:
I have an intermittent segfault with one particular ResponseHandler.
The segfault, when it occurs, is triggered by calling $r->content_type
in a lightly modified CGI::Simple (I made changes to it as it wasn't
playing well with mod_perl2). What might be go
On 25.06.2008, at 20:58, Amiri Barksdale wrote:
I had big trouble with DBD::mysql 4.007. I didn't get rid of my
segfault problem running mod_perl 1.31 until I went back to 4.004.
Thanx. It really looks a lot like my problem:
http://bugs.mysql.com/bug.php?id=36810
I'll try rever
I had big trouble with DBD::mysql 4.007. I didn't get rid of my
segfault problem running mod_perl 1.31 until I went back to 4.004.
Amiri
On Jun 25, 2008, at 12:14 PM, Perrin Harkins wrote:
On Wed, Jun 25, 2008 at 5:49 AM, Tobias Kremer <[EMAIL PROTECTED]>
wrote:
After de-ins
sound like this is a problem with the new DBD::mysql then, rather
than Apache::DBI. If you want to determine that the problem is the
version and not your compile options, you can compile the Ubuntu
versions yourself and see if they segfault.
Another possibility here is that although Apache::DBI
Quoting André Warnier <[EMAIL PROTECTED]>:
> I don't know if the above versions are imposed to you, but in case you
> have a choice, I would recommend de-installing your Apache and mod_perl,
> and re-install the Apache 2.2 version and the mod_perl that goes with it.
> Apache 1.x and mod_perl 1.x ar
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> > - Ubuntu Feisty with apache-perl.
> > - stock Ubuntu Perl 5.8.8 (which unfortunately comes with threads)
> > - self-rolled DBD::mysql (against libmysqlclient15-dev), DBI and
> Apache::DBI
>
> I should have mentioned that we're using DBI 1.605, Apache:
> - Ubuntu Feisty with apache-perl.
> - stock Ubuntu Perl 5.8.8 (which unfortunately comes with threads)
> - self-rolled DBD::mysql (against libmysqlclient15-dev), DBI and Apache::DBI
I should have mentioned that we're using DBI 1.605, Apache::DBI 1.07 and
DBD::mysql 4.007. The Ubuntu apache-perl
We have a mod_perl application that needs to connect to the database during
Apache startup to prefetch some data. The database handle for this is not
stored or re-used in any way.
According to the documentation, Apache::DBI does not cache database connections
made during server startup, so I shoul
Fred Moyer wrote:
>
> What version were you using that was causing the problems?
>
4.007.
Amiri
--
View this message in context:
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17675687.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
What version were you using that was causing the problems?
amiribarksdale wrote:
It appears that downgrading DBD::mysql to version 4.004 has done the trick.
Amiri
--
Red Hot Penguin Consulting LLC
mod_perl/PostgreSQL consulting and implementation
http://www.redhotpenguin.com/
It appears that downgrading DBD::mysql to version 4.004 has done the trick.
Amiri
--
View this message in context:
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17668030.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
I reinstalled mysql from source and recompiled my DBD::mysql against
its new libs, and I still get the same backtrace:
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
...
#0 0x002a994cf93e in mysql_send_query ()
from /home/mysql/lib/mysql/libmysqlclient.so.15
(gdb) bt fu
n/data',
error_mode => 'output',
allow_globals => [ qw( $User ) ],
args_method => 'mod_perl',
),
);
sub handler {
my $r = shift;
$ah{$r->dir_config('site')}->handle_request($r);
}
1;
--
View this message in context:
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17633171.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
s. I just built everything back up from
barebones CentOS.
From my cursory look through the stack trace it looks like the segfault
is occurring when the database connections are being closed, either as a
result of the httpd child dying, or the apache dbi connection closing.
Apache::DBI
recompile and reinstall everything, because of
>> those 32-bit and 64 bit errors. I just built everything back up from
>> barebones CentOS.
>
> From my cursory look through the stack trace it looks like the segfault
> is occurring when the database connections are being closed,
h the stack trace it looks like the segfault
is occurring when the database connections are being closed, either as a
result of the httpd child dying, or the apache dbi connection closing.
Apache::DBI disconnect (overloaded)
Try setting the debug level for Apache::DBI to 2 to get ve
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17629499.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
amiribarksdale wrote:
Yes, I moved from 32 bit to 64 bit. But I did exactly what you said. I
reinstalled everything--perl, apache, mysql, DBI, DBD::mysql, every single
module--the whole shebang. So it's not just some careless oversight or file
copy. Everything has already been rebuilt and recompi
View this message in context:
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17628964.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
amiribarksdale wrote:
Does anyone have any guidance on what I should do here?
Amiri
From the archive thread: -
http://www.nabble.com/Segfault-Help%21-%21--tp17599739p17627528.html
"Here are two short snippets of gdb output from the other evening. Can
someone lead me in the right dire
1 - 100 of 264 matches
Mail list logo
