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] [Announce] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Fri, Dec 05, 2008 at 04:25:49PM +0100, Marcus Ramberg wrote:
There are still a few problems to solve before the next stable CPAN
release (Some of the plugins are still failing tests, most notoriously the
backwards compatibility tests of Catalyst-Plugin-Authentication), but
Catalyst-Runtime now works on our apps. That is why we would like for you
to try it out, and tell us what breaks on your apps (If you don't, we will
happily ignore your anguished cries later (Well, probably not, but please
test it anyways!)) The developer release is currently on it's way to
CPAN, and should be available for your local mirror before long. In case
you are interested, I've included the change log since the last dev
release below.
I don't know if I've done something stupid somewhere.
Running the tests for Catalyst-Runtime-5.8000_04 passes:
All tests successful.
Files=40, Tests=2106, 57 wallclock secs ( 0.68 usr 0.20 sys + 46.77 cusr
1.80
MyApp is fine under 5.7014, starting it with:
PERL5LIB=${HOME}/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib
CATALYST_DEBUG=1 DBIC_TRACE=1 ./script/parley_server.pl
--host=localhost -r -rd 2 --port=3000
any hits to the app give me the following:
[info] *** Request 3 (0.005/s) [11697] [Mon Dec 8 22:05:46 2008] ***
[error] Caught exception in engine Attribute (headers) does not pass the type
constraint because: Validation failed for 'Header' failed with value
HTTP::Headers=HASH(0xa6dee88) at
/usr/local/share/perl/5.10.0/Moose/Meta/Class.pm line 193
Moose::Meta::Class::construct_instance('Moose::Meta::Class=HASH(0x95e96a8)',
'HASH(0xa6de8a8)') called at /usr/local/lib/perl/5.10.0/Class/MOP/Class.pm line
388
Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x95e96a8)',
'HASH(0xa6de8a8)') called at /usr/local/share/perl/5.10.0/Moose/Meta/Class.pm
line 157
Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x95e96a8)',
'HASH(0xa6de8a8)') called at /usr/local/share/perl/5.10.0/Moose/Object.pm line
17
Moose::Object::new('Parley', 'HASH(0xa6de888)') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst.pm
line 1671
Catalyst::prepare('Parley') called at
/usr/local/share/perl/5.10.0/Catalyst/Plugin/FormValidator.pm line 35
Catalyst::Plugin::FormValidator::prepare('Parley') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst.pm
line 1638
eval {...} called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst.pm
line 1630
Catalyst::handle_request('Parley') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst/Engine/HTTP.pm
line 375
Catalyst::Engine::HTTP::_handler('Catalyst::Engine::HTTP::Restarter=HASH(0x9a8ecd8)',
'Parley', 3000, 'GET', '/forum/list', 'HTTP/1.1') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst/Engine/HTTP.pm
line 281
Catalyst::Engine::HTTP::run('Catalyst::Engine::HTTP::Restarter=HASH(0x9a8ecd8)',
'Parley', 3000, 'localhost', 'HASH(0x9337648)') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst/Engine/HTTP/Restarter.pm
line 70
Class::MOP::Class:::around('CODE(0x8fa3af8)',
'Catalyst::Engine::HTTP::Restarter=HASH(0x9a8ecd8)', 'Parley', 3000,
'localhost', 'HASH(0x9337648)') called at
/usr/local/lib/perl/5.10.0/Class/MOP/Method/Wrapped.pm line 129
Class::MOP::Method::Wrapped::__ANON__('Catalyst::Engine::HTTP::Restarter=HASH(0x9a8ecd8)',
'Parley', 3000, 'localhost', 'HASH(0x9337648)') called at
/usr/local/lib/perl/5.10.0/Class/MOP/Method/Wrapped.pm line 89
Catalyst::Engine::HTTP::Restarter::run('Catalyst::Engine::HTTP::Restarter=HASH(0x9a8ecd8)',
'Parley', 3000, 'localhost', 'HASH(0x9337648)') called at
/home/chisel/development/open_source/dev-tests/Catalyst-Runtime-5.8000_04/lib/Catalyst.pm
line 1934
Catalyst::run('Parley', 3000, 'localhost', 'HASH(0x9337648)') called at
./script/parley_server.pl line 57
Is this likely to be my stupidity?
--
Chisel Wright
e: [EMAIL PROTECTED]
w: http://www.herlpacker.co.uk/
All complaints must be submitted in writing
on the back of a ten pound note.
___
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] [Announce] Catalyst-Runtime 5.8000_04 shipped to CPAN
On 8 Dec 2008, at 23:15, Bill Moseley wrote: This suppose to be drop-in compatible with 5.7? That's the aim, although we're probably not there yet.. perl, v5.10.0 All tests pass building Catalyst-Runtime but it's very noisy: Subroutine uninitialize redefined at /usr/share/perl5/Class/C3.pm line 88. Subroutine reinitialize redefined at /usr/share/perl5/Class/C3.pm line 101. But, I suspect that's 5.10.0 on this test machine. I had to clean up a bunch of those for my apps when I upgraded as well. This has been fixed in trunk I believe. Running make test on an application that passes all tests with 5.7015 results in: Failed 14/113 test scripts. 325/616 subtests failed. Files=113, Tests=616, 127 wallclock secs (60.45 cusr + 4.38 csys = 64.83 CPU) Failed 14/113 test programs. 325/616 subtests failed. Sorry, I didn't have time to look into this, so I'll just paste a few errors I saw: A few private plugins and views complain that NEXT is crap. Hopefully I'll find time to get those updated before the current non-crap becomes crap, too. It's possible to suppress that warning by saying no warnings 'Class::C3::Adopt::NEXT'; in the offending code until you get it ported to Class::C3's next::method. You can do this right now (as next::method works in 5.7). Writing a little more advice for this for the POD is on my todo list. Suggested doc fixes (and suggestions to make the warning better) gratefully received if you have any. A few failed the Class::MOP::is_class_loaded($class) test. require App::Model::Foo was successful but the package is not defined This means that you have a file 'lib/App/Model/Foo.pm, but that file doesn't appear to define package App::Model::Foo. I'd guess that your app is subtly broken in some way (like the file being mis-named) which is causing Class::MOP to not like the file. Is that true for your application, and can you think of a better wording which would make the error message more clear/explicit about the problem? Also: Compilation failed in require at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 151. Undefined subroutine Test::WWW::Mechanize::Catalyst::Aux::request There's a fair amount of noise due to that, but I think that's causing the build of the test failures. Yeah, that'd figure - I guess there are stack traces to go with this? I suspect this is doing the most damage: require App::Model::Foo was successful but the package is not defined which is not entirely clear what that means. Hopefully explained above. If you could run the tests again manually with prove -v, and email me the results off-list then it'd help me diagnose the issues you're seeing further. Many thanks for the help! Cheers t0m ___ 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/
[Catalyst] Example app showing user to item authorization?
Hi. I'm relatively new to Catalyst. Also, since I'm not a programmer by trade I only get to spend a few hours a week on code so I'm a bit rusty on some stuff. I've built a basic project / task system. User creates project then creates tasks for that project. The tasks can be assigned to other users for completion. However, the next bit of logic I need to build is to only allow users assigned to the task to edit that task. I've setup two tables in the database (MySQL) to store the relationships: project_user (project_id, user_id) task_user (task_id, user_id) I've code written for authenticating users against MySQL so only people who register can access the system, but right now any authenticated user can access any project or task. I've found the Authorization::Roles Authorization::ACL modules, but they seem to only be for higher level access. Perhaps I'm missing something. So my question: is there an example application or best practice on how to implement a check on all calls to see if the user should be accessing a specific item? I guess this would apply to any type of system: blog, auction, cms, etc. -- they all require checking if a specific user can edit a specific item. Thanks! Cheers, chunk ___ 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/
[Catalyst] Emulate a tar pit for OpenID tests
I want emulate a trap URL to test the OpenID stuff. The real world
case is someone using a malicious OpenID URI which would effectively
be a DoS against the OpenID consumer site by tying up processes (and
bandwidth in a real attack). They'd go to initiate the OpenID
transfers with the malicious URI and get stuck waiting and
downloading huge amounts of data.
I guess I can just do something like-
sub tarpit : Global {
my ( $self, $c ) = @_;
local $/ = 1;
$c-response-content_type(text/html);
# Expect an arbitrary, biggish amount of content; it's a lie.
$c-response-headers-header(Content-length = 1_024 * 1_000);
sleep 1 $c-response-write(sucker\n) while 1; # Send
content forever, slowly.
}
So, my question for y'all is: How does that look? Better ideas? Is
that close to a real world (operationally) case?
-Ashley
___
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/
