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.
>>>
>>
>>
>
--
___________________________________________________
__
|- giannici@stripped
|ederico Giannici http://www.neomedia.it
___________________________________________________
