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.
BTW - how does it work if you use server-side prepare?
Kind regards,
Patrick
> 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.
>>>>
>
>
