Hi Patrick,
I have seen that version 3.0007 has been released and it (should) have
fixed that bug.
But...
1) In mysql_st_internal_execute() the "bind_type_guessing" variable is
correctly set, but then it's NOT used: "imp_dbh->bind_type_guessing" is
still used!
2) mysql_st_internal_execute() is used in only two places. Instead of
doing all that tests at the beginning of the function to handle both
cases (STH and DBH for the "h" parameter), why don't you change the type
of the first parameter into a "imp_dbh"? Wouldn't everything be clearer
this way?
Bye.
Federico Giannici wrote:
Hi Patrick,
are there any news about this bug?
Someone made me notice that there a few other "tickets" open on this bug
(under i386 and amd64), like this one:
http://rt.cpan.org/Public/Bug/Display.html?id=20868
Thanks.
Patrick Galbraith wrote:
Federico,
That may be the issue. I have encountered this issue in other parts of
the driver. There is a better way to do this, and I can look at making
sure what is being passed is the same data object.
Thanks!
Patrick
Federico Giannici wrote:
Since there has been no reply to my previous message, I have done
further investigations trying to find the problem.
Please note that my knowledge of DBI/DBD is almost null, so the
followings are only simple suppositions.
I have seen that mysql_st_internal_execute() function is executed by
both the "do" and "execute" methods. It seems that the problems are
only with the "do" method and not with the "execute", so I looked for
the differences between them.
The main difference seems to be that "execute" passes a STATEMENT
handle as first argument, while "do" passes a DATABASE handle. The
mysql_st_internal_execute() function uses this handle to obtain the
sth and then from this one the dbh.
So, my hypothesis is that if the initial handle is a database one,
the sth (and the derived dbh) obtained from this is not a valid one!
Anybody can confirm (or negate) this wild hypothesis?
Thanks.
P.S.
I want to repeat that the problem manifest itself only under OpenBSD
because of it's memory management that cause the program to segfault
if try to access a non allocated memory. In other operating systems,
a random value is get for "imp_dbh->bind_type_guessing", which is
almost irrelevant.
Federico Giannici wrote:
It seems to me that there is some kind of memory access problem with
DBI or DBD-Mysql.
I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the problem
didn't appeared. As you may know, recent version of OpenBSD have a
new kind of memory handling that make the programs segfault when
they try to access no (longer) allocated memory.
I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and
DBD-Mysql 3.0006, but the problems were more frequent, so I remained
to the old versions.
Here is the problem: frequently some "do" commands cause perl to
crash with signal 11. The crashes seems to depend on a lot of
factors. For example, loading more libraries could make the program
to start working. I think it depends on the structure of the memory
allocated to the program.
Here is the "bt" output of the core dump:
#0 0x000000005260a736 in mysql_st_internal_execute (h=0x4713b6e0,
statement=0x479b7140, attribs=0x4aa5fd40, numParams=0, params=0x0,
cdaPtr=0x7f7ffffc8610, svsock=0x43c90498,
use_mysql_use_result=0) at dbdimp.c:1654
#1 0x0000000052612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at
mysql.xs:222
#2 0x0000000050ddf07b in XS_DBI_dispatch () from
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so
#3 0x000000004a5a1c47 in Perl_pp_entersub () at
/usr/src/gnu/usr.bin/perl/pp_hot.c:2890
#4 0x000000004a60899e in Perl_runops_standard () at
/usr/src/gnu/usr.bin/perl/run.c:37
#5 0x000000004a5f744d in S_run_body (oldscope=1) at
/usr/src/gnu/usr.bin/perl/perl.c:1936
#6 0x000000004a5f7231 in perl_run (my_perl=0x45356258) at
/usr/src/gnu/usr.bin/perl/perl.c:1855
#7 0x0000000000401afe in main ()
I have found the problem is caused by accessing
"imp_dbh->bind_type_guessing" for the call to ParseParam() inside
mysql_st_internal_execute().
I have verified that "imp_dbh" is NOT null, but trying to access any
member make the program segfault. So maybe the pointer is a stale one?
I have not enough knowledge of DBI to make more debugging.
Bye.
--
___________________________________________________
__
|- [EMAIL PROTECTED]
|ederico Giannici http://www.neomedia.it
___________________________________________________
