Patrick Galbraith wrote:
Federico Giannici wrote:
Federico,
Hmm.... One of the problems I had is that I didn't have a Open BSD box
to test this out. Perhaps your second suggestion might be a solution to
pursue. I would prefer that the argument to mysql_st_internal_execute
take one type of argument.
I agree that the second solution is the preferred one (much simpler and
even more efficient).
Anyway, to make the first solution to work, you have simply to
substitute "imp_dbh->bind_type_guessing" with "bind_type_guessing" as
the last argument to parse_params()...
BTW - how does it work if you use server-side prepare?
Our MySQL server is still version 4.0, so we cannot use server-side
prepares...
Bye.
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
___________________________________________________
