Re: DBD::mysql 4.006 SEGVing on Solaris sparc

Hi!

I would not  use the threaded perl. The docs state ("perldoc DBD::mysql")

 The multithreading capabilities of DBD::mysql depend completely on the
       underlying C libraries: The modules are working with handle data 
only,
       no global variables are accessed or (to the best of my knowledge)
       thread unsafe functions are called. Thus DBD::mysql is believed to be
       completely thread safe, if the C libraries are thread safe and you
       don't share handles among threads.

       The obvious question is: Are the C libraries thread safe?  In the 
case
       of MySQL the answer is "mostly" and, in theory, you should be able to
       get a "yes", if the C library is compiled for being thread safe (By
       default it isn't.) by passing the option -with-thread-safe-client to
       configure. See the section on How to make a threadsafe client in the
       manual.

This suggestion "--with-thread-safe-client" may be the answer. It'll 
require that you build MySQL with this option and not use stock binaries.

Here's some more, from the DBI perldoc:

But BEWARE, some underlying database APIs (the code the DBD driver uses
       to talk to the database, often supplied by the database vendor) 
are not
       thread safe. If it's not thread safe, then allowing more than one
       thread to enter the code at the same time may cause subtle/serious
       problems. In some cases allowing more than one thread to enter the
       code, even if not at the same time, can cause problems. You have been
       warned.

       Using DBI with perl threads is not yet recommended for production 
envi-
       ronments. For more information see <http://www.perl-
       monks.org/index.pl?node_id=288022>

If you search "problems threaded perl DBI" on Google, you'll see other 
situations where people have encountered problems with threaded perl.

I hope this information helps.

regards,

Patrick

[email protected] wrote:

> We're having a problem with DBD::mysql SEGVing on Solaris sparc - both
> with Solaris 9 and Solaris 10.  Solaris x86 is working OK.
>
> With a tiny test script:
>
> """
> use strict;
> use warnings;
>
> use DBI;
> use DBD::mysql;
>
> my $server = "something";
> my $user   = "root";
> my $pass   = "foobar";
>
> my $dbh = DBI->connect( "DBI:mysql:mysql:$server", $user, $pass,
>             { AutoCommit => 1, PrintError => 0 } )
>           or die "Cannot connect - " . DBI->errstr;
>
> print "Have a DB handle: $dbh\n";
> """
>
>
> we get "Segmentation Fault (core dumped)" rather than the expected
> "Cannot connect - Unknown MySQL server host 'something' (1)"
>
> This is with our own builds of Perl 5.8.8, DBI 1.602, and DBD-mysql 4.006
> Perl is built with threading enabled.
>
> A backtrace reveals:
>
> ffbfec58 mysql.so`XS_DBD__mysql__db__login+0x228(0, 1af6dc, 4, 4, 
> fffeee90, 0)
> ffbfecc0 libperl.so`Perl_pp_entersub+0x888(23778, 1418d0, 0, 0, 
> 1b06c4, 1c0d40)
> ffbfed78 libperl.so`Perl_runops_debug+0x464(23778, ffbfef64, ff2b7884, 
> ff38a950,
> ff393838, 40000)
> ffbfede0 libperl.so`Perl_call_sv+0x314(23778, d5748, 0, 0, fef36f90, 
> 1b8768)
> ffbfef98 DBI.so`XS_DBI_dispatch+0x24b4(23778, 1ecf08, 5, 1e60e0, 0, 0)
> ffbff4e0 libperl.so`Perl_pp_entersub+0x888(23778, f1a80, 0, 0, 80000, 
> 19c07c)
> ffbff598 libperl.so`Perl_runops_debug+0x464(23778, 1, ff2b7884, ff38a950,
> ff393838, 40000)
> ffbff600 libperl.so`S_run_body+0x1f8(39600, 244d8, 0, 1, 2397c, 23778)
> ffbff660 libperl.so`perl_run+0x2a8(23778, ffbff6e0, 2, 23778, 0, 2397c)
> ffbff760 main+0xf0(2, ffbff824, 11800, 14, 0, 233d4)
> ffbff7c0 _start+0x108(0, 0, 0, 0, 0, 0)
>
> and looking at the code around mysql.so`XS_DBD__mysql__db__login+0x228
> we see:
>
> /* 0x0218         88 */         call    Perl_get_sv     ! params =  
> %o0 %o1 %o2
> ! Result =  %o0
> /* 0x021c            */         ld      [%l0+%i4],%o1,%gdop(.L114)
> /* 0x0220            */         ld      [%o0],%g5
> /* 0x0224            */         ld      [%g5+16],%i5
> /* 0x0228            */         ld      [%i5+24],%g4                  
> <=====
> /* 0x022c            */         jmpl    %g4,%o7
> /* 0x0230            */         or      %g0,%l4,%o0
>
> Note that on the Sparc processor the code at 0x021c is actually
> executed BEFORE the call.
>
> We're calling Perl_get_sv() with an argument of 'DBI::_dbistate'
> which returns a structure in register o0.
> We then load from o0 with an offset of 16 into register i5, and
> this is a null pointer. The load at 0x0228 is then attempting to read
> from a small offset from 0x00000000 - hence the segment violation.
>
> Well, we can debug this far but now we're stuck.
>
> If we build Perl 5.8.8 without threading, then the problem is not
> present - but this looks like a workaround rather than a fix.
>
> Seems like the lookup of 'DBI::_dbistate' fails on a threaded
> Perl, and the code isn't expecting that.
>
> Any ideas please ?
>


-- 
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 

Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad




-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/[email protected]