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

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
___________________________________________________

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