Re: [Catalyst] Catalyst modperl - child process segmentation fault
Terence Monteiro ha scritto:
[snip]
not happen? I am initializing the database connection in a Controller. Is
there any problem in this, though it may not be the best design. Will
putting the database initialization code in the Model help? I have included
afaict, you should let dbic / cat-model handle the connection to the
database. I usually use something like this: a
MyApp/Model/Main.pm
package which inherits from e.g.
Catalyst::Model::DBIC::Schema
and calls
__PACKAGE__-config(
schema_class = 'MyApp::Schema',
connect_info = [ $dsn, $user, $pass, $options ],
);
This way I don't explicitly connect at startup, but let the framework
perform the actual connection when needed (i.e. at first db access, with
something like $c-model('Main')-resultset('Users')-find($id))
[snip]
HTH
--
Marcello Romani
Responsabile IT
Ottotecnica s.r.l.
http://www.ottotecnica.com
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Terence Monteiro wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp Following are the package versions: apache2 2.2.9-10 apache2-dbg 2.2.9-11 apache2-mpm-prefork 2.2.9-11 apache2-utils 2.2.3-4+etch6 apache2.2-common2.2.9-11 libapache2-mod-auth-pam 1.1.1-6.1 libapache2-mod-auth-sys-group 1.1.1-6.1 libapache2-mod-fastcgi 2.4.6-1 libapache2-mod-perl22.0.4-4 libapache2-mod-php5 5.2.0-8+etch10 libapache2-reload-perl 0.10-2 Catalyst and Perl module versions are: Catalyst5.7014 DBIx::SearchBuilder 1.54 mysql-server-5.05.0.32-7etch5 I did a backtrace, which I posted to the modperl mailing list. One reply said that the cause may be initializing a DB handle at startup and using it in the child process. What needs to be done differently to ensure this does not happen? Is it necessary to close open database handles after handling each HTTP request? Should I add code in my begin and end actions to open and close handles each time? I'm still pulling off hair on this segfault problem. I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so #2 0xb6e03088 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so #3 0xb7686975 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #4 0xb7684d91 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #5 0xb767ed08 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #6 0xb774ebfc in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #7 0xb774f2d3 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #8 0xb774f9ca in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #9 0xb77486ef in modperl_response_init () from /usr/lib/apache2/modules/mod_perl.so #10 0xb77488a3 in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #11 0x0807a179 in ap_run_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:159 #12 0x0807d591 in ap_invoke_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:373 #13 0x0808aff6 in ap_process_request (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:258 #14 0x08088128 in ap_process_http_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/modules/http/http_core.c:190 #15 0x080815a9 in ap_run_process_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/server/connection.c:43 #16 0x0808fc0c in child_main (child_num_arg=value optimized out) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:672 #17 0x0808ff63 in make_child (s=0x80ab908, slot=0) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:769 #18 0x08090d68 in ap_mpm_run (_pconf=0x80a70c8, plog=0x80d9190, s=0x80ab908) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:904 #19 0x08066f10 in main (argc=Cannot access memory at address 0x0 ) at /tmp/buildd/apache2-2.2.9/server/main.c:732 I don't face the problem when I run apache as a single process (MaxClients = 1). -- Thanks and Regards, Terence Monteiro. DeepRoot Linux, http://www.deeproot.in Ph: +91 (80) 4089 Getting GNU/Linux to work for you. Faster. Better. Today. Every way ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
On Mon, Jan 5, 2009 at 3:15 AM, Terence Monteiro tere...@deeproot.co.in wrote: Is it necessary to close open database handles after handling each HTTP request? Should I add code in my begin and end actions to open and close handles each time? I'm still pulling off hair on this segfault problem. It shouldn't be necessary. You completely throw away the benefits of connection pooling if you create/teardown a db connection every single webpage access. I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? Model here, works well for us. Ultimately it's up to your if you want to try. I'm not expert enough to know whether it would make a difference. #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so What's your max clients set to in mysql? How many connections are open? (show processlist when logged in to mysql as root will be most illuminating). What's your connection_timeout set to? If you have a short connection timeout, then low traffic will result in db connections getting closed by mysql, which DBI only handles if your code is written to handle it (though I don't expect this to be a problem because your description seems to imply a problem on startup, not while running). I don't face the problem when I run apache as a single process (MaxClients = 1). Another problem we had was if you configured pam/nss to use LDAP, when apache started and tried to create all the threads at once, not all threads were able to get the uid from nss, so some would be the apache user, and some would still be root. Was very strange. But that doesn't sound like what you're seeing either. Good luck! -- Regards... Todd All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Hi, This looks like the general DBI multi-process issue. When you fork any child processes, any variables in the parent process are copied across, this includes the filehandle no. for the socket to the mysql server. All of a sudden you have 50 processes talking down the same wire. What you want to do is disconnect (but not destroy) the database handle before forking and then get each child to reconnect() themselves (DBI can deal with pooling transparently, iirc). Apache::DBI does this for you, but iirc it doesn't _quite_ work correctly. ta! -- -Scott McWhirter- | -konobi- On Mon, Jan 5, 2009 at 11:40, Todd Lyons tly...@ivenue.com wrote: On Mon, Jan 5, 2009 at 3:15 AM, Terence Monteiro tere...@deeproot.co.in wrote: Is it necessary to close open database handles after handling each HTTP request? Should I add code in my begin and end actions to open and close handles each time? I'm still pulling off hair on this segfault problem. It shouldn't be necessary. You completely throw away the benefits of connection pooling if you create/teardown a db connection every single webpage access. I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? Model here, works well for us. Ultimately it's up to your if you want to try. I'm not expert enough to know whether it would make a difference. #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so What's your max clients set to in mysql? How many connections are open? (show processlist when logged in to mysql as root will be most illuminating). What's your connection_timeout set to? If you have a short connection timeout, then low traffic will result in db connections getting closed by mysql, which DBI only handles if your code is written to handle it (though I don't expect this to be a problem because your description seems to imply a problem on startup, not while running). I don't face the problem when I run apache as a single process (MaxClients = 1). Another problem we had was if you configured pam/nss to use LDAP, when apache started and tried to create all the threads at once, not all threads were able to get the uid from nss, so some would be the apache user, and some would still be root. Was very strange. But that doesn't sound like what you're seeing either. Good luck! -- Regards... Todd All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
On Wed, Dec 10, 2008 at 2:20 PM, Terence Monteiro [EMAIL PROTECTED] wrote: How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? Disabled mod_php5 and tried again. Still get the segfaults. Has anyone else faced this problem, with segmentation faults while running their Catalyst app with mod_perl 2.0.4-4 on apache 2.2.9-10 or 2.2.9-11 on debian? Install DBD::mysql 4.006 or try 4.010. Versions 4.007 and 4.008 caused segfaults exactly like the one you got. The changelog of 4.009 says this bug has been fixed, so you could try 4.010: * Fix to re-enable TAKE_IMP_DATA_VERSION. Still have to ensure DBI version 1.607 or higher But I haven't tried this version yet. 4.006 works fine for me and at that time, the latest was 4.008 so I went back to 4.006. Sergio Salvi ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp Following are the package versions: apache2 2.2.9-10 apache2-dbg 2.2.9-11 apache2-mpm-prefork 2.2.9-11 apache2-utils 2.2.3-4+etch6 apache2.2-common2.2.9-11 libapache2-mod-auth-pam 1.1.1-6.1 libapache2-mod-auth-sys-group 1.1.1-6.1 libapache2-mod-fastcgi 2.4.6-1 libapache2-mod-perl22.0.4-4 libapache2-mod-php5 5.2.0-8+etch10 libapache2-reload-perl 0.10-2 Catalyst and Perl module versions are: Catalyst5.7014 DBIx::SearchBuilder 1.54 mysql-server-5.05.0.32-7etch5 I did a backtrace, which I posted to the modperl mailing list. One reply said that the cause may be initializing a DB handle at startup and using it in the child process. What needs to be done differently to ensure this does not happen? I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so #2 0xb6e03088 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so #3 0xb7686975 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #4 0xb7684d91 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #5 0xb767ed08 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #6 0xb774ebfc in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #7 0xb774f2d3 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #8 0xb774f9ca in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #9 0xb77486ef in modperl_response_init () from /usr/lib/apache2/modules/mod_perl.so #10 0xb77488a3 in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #11 0x0807a179 in ap_run_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:159 #12 0x0807d591 in ap_invoke_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:373 #13 0x0808aff6 in ap_process_request (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:258 #14 0x08088128 in ap_process_http_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/modules/http/http_core.c:190 #15 0x080815a9 in ap_run_process_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/server/connection.c:43 #16 0x0808fc0c in child_main (child_num_arg=value optimized out) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:672 #17 0x0808ff63 in make_child (s=0x80ab908, slot=0) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:769 #18 0x08090d68 in ap_mpm_run (_pconf=0x80a70c8, plog=0x80d9190, s=0x80ab908) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:904 #19 0x08066f10 in main (argc=Cannot access memory at address 0x0 ) at /tmp/buildd/apache2-2.2.9/server/main.c:732 Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. I've definitely seen that cause segfaults in apache, when perl and php are linked to different versions of the mysql library. -Toby -- Thanks and Regards, Terence Monteiro. DeepRoot Linux, http://www.deeproot.in Ph: +91 (80) 4089 Getting GNU/Linux to work for you. Faster. Better. Today. Every way ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp Following are the package versions: apache2 2.2.9-10 apache2-dbg 2.2.9-11 apache2-mpm-prefork 2.2.9-11 apache2-utils 2.2.3-4+etch6 apache2.2-common2.2.9-11 libapache2-mod-auth-pam 1.1.1-6.1 libapache2-mod-auth-sys-group 1.1.1-6.1 libapache2-mod-fastcgi 2.4.6-1 libapache2-mod-perl22.0.4-4 libapache2-mod-php5 5.2.0-8+etch10 libapache2-reload-perl 0.10-2 Catalyst and Perl module versions are: Catalyst5.7014 DBIx::SearchBuilder 1.54 mysql-server-5.05.0.32-7etch5 I did a backtrace, which I posted to the modperl mailing list. One reply said that the cause may be initializing a DB handle at startup and using it in the child process. What needs to be done differently to ensure this does not happen? I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so #2 0xb6e03088 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so #3 0xb7686975 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #4 0xb7684d91 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #5 0xb767ed08 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #6 0xb774ebfc in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #7 0xb774f2d3 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #8 0xb774f9ca in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #9 0xb77486ef in modperl_response_init () from /usr/lib/apache2/modules/mod_perl.so #10 0xb77488a3 in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #11 0x0807a179 in ap_run_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:159 #12 0x0807d591 in ap_invoke_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:373 #13 0x0808aff6 in ap_process_request (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:258 #14 0x08088128 in ap_process_http_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/modules/http/http_core.c:190 #15 0x080815a9 in ap_run_process_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/server/connection.c:43 #16 0x0808fc0c in child_main (child_num_arg=value optimized out) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:672 #17 0x0808ff63 in make_child (s=0x80ab908, slot=0) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:769 #18 0x08090d68 in ap_mpm_run (_pconf=0x80a70c8, plog=0x80d9190, s=0x80ab908) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:904 #19 0x08066f10 in main (argc=Cannot access memory at address 0x0 ) at /tmp/buildd/apache2-2.2.9/server/main.c:732 I don't face the problem when I run apache as a single process (MaxClients = 1). -- Thanks and Regards, Terence Monteiro. DeepRoot Linux, http://www.deeproot.in Ph: +91 (80) 4089 Getting GNU/Linux to work for you. Faster. Better. Today. Every way ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
On Monday 08 December 2008 02:20:38 am Terence Monteiro wrote: How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. (answering just this part) because, assuming you use mod_php, and your PHP is built to support mysql (it almost always is), then PHP will be linked against libmysqlcient, and apache will link in mod_php at runtime, bringing in mysql by reference. Then your mod_perl app uses DBI, which also dlopens libmysqlclient, and hilarity ensues. To answer your question of how?, I'd suggest ldd'ing the appropriate components -- mod_php.so and auto/DBD/mysql/mysql.so. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp ]snip] Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? To check the actual versions of libraries used, you can do: ldd /usr/lib/apache2/modules/mod_php*.so ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so (At least I'm pretty sure that's where the files should be on debian etch) But if you've recompiled dbd::mysql from source, and not mod_php, then I'll bet this IS the problem. Sorry. -Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Toby Corkindale wrote: Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp ]snip] Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? Thanks for the reply. I have switched to fastcgi deployment and so far have not had any segfaults. I will try what you're saying tonight, since being a production environment, I get downtime only after 7:30pm IST (0100 UTC). To check the actual versions of libraries used, you can do: ldd /usr/lib/apache2/modules/mod_php*.so ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so (At least I'm pretty sure that's where the files should be on debian etch) But if you've recompiled dbd::mysql from source, and not mod_php, then I'll bet this IS the problem. Sorry. I installed both DBD::mysql and mod_php from debian packages (libdbd-mysql-perl and libapache2-mod-php5). I did not compile DBD::mysql (never have before). ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so: ... libmysqlclient.so.15 = /usr/lib/libmysqlclient.so.15 (0xb7d04000) ... The only .so file I can find on libapache2-mod-php5 deb package is /usr/lib/apache2/modules/libphp5.so, but running ldd on it does not yield any mysql client libraries. The output is: linux-gate.so.1 = (0xe000) libcrypt.so.1 = /lib/libcrypt.so.1 (0xb79ff000) libz.so.1 = /usr/lib/libz.so.1 (0xb79ea000) libssl.so.0.9.8 = /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb79a3000) libdb-4.6.so = /usr/lib/libdb-4.6.so (0xb787) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb786) libpcre.so.3 = /usr/lib/libpcre.so.3 (0xb7831000) libresolv.so.2 = /lib/libresolv.so.2 (0xb781f000) libm.so.6 = /lib/libm.so.6 (0xb77fa000) libdl.so.2 = /lib/libdl.so.2 (0xb77f5000) libnsl.so.1 = /lib/libnsl.so.1 (0xb77de000) libgssapi_krb5.so.2 = /usr/lib/libgssapi_krb5.so.2 (0xb77b4000) libkrb5.so.3 = /usr/lib/libkrb5.so.3 (0xb772) libk5crypto.so.3 = /usr/lib/libk5crypto.so.3 (0xb76fc000) libcom_err.so.2 = /lib/libcom_err.so.2 (0xb76f9000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0xb75bf000) libc.so.6 = /lib/libc.so.6 (0xb748a000) libcrypto.so.0.9.8 = /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7337000) libpthread.so.0 = /lib/libpthread.so.0 (0xb732) /lib/ld-linux.so.2 (0x8000) libkrb5support.so.0 = /usr/lib/libkrb5support.so.0 (0xb7318000) libkeyutils.so.1 = /lib/libkeyutils.so.1 (0xb7314000) -Toby -- Thanks and Regards, Terence Monteiro. DeepRoot Linux, http://www.deeproot.in Ph: +91 (80) 4089 Getting GNU/Linux to work for you. Faster. Better. Today. Every way ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp ]snip] Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? Thanks for the reply. I have switched to fastcgi deployment and so far have not had any segfaults. I will try what you're saying tonight, since being a production environment, I get downtime only after 7:30pm IST (0100 UTC). To check the actual versions of libraries used, you can do: ldd /usr/lib/apache2/modules/mod_php*.so ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so (At least I'm pretty sure that's where the files should be on debian etch) But if you've recompiled dbd::mysql from source, and not mod_php, then I'll bet this IS the problem. Sorry. I installed both DBD::mysql and mod_php from debian packages (libdbd-mysql-perl and libapache2-mod-php5). I did not compile DBD::mysql (never have before). Ah, sorry, I mistook something. But I do think you said you installed the DBD::Mysql from a debian backports, whereas the mod_php was from etch stable? So, the Debian crew have done the compiling for you, but still, the DBD::mysql is linked against mysqlclient from backports, while mod_php is linked against the stable mysql client libraries. Another test would be to update all of perl, apache, mod_php, dbd::mysql, mod_perl etc from backports, so at least everything is from the same source. tjc ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
