Re: Memory access problem with DBI or DBD-Mysql?

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
___________________________________________________

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