Memory access problem with DBI or DBD-Mysql?

am 12.08.2006 14:25:03 von giannici

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/DB I.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@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

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

am 15.08.2006 15:37:31 von Federico Giannici

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/DB I.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@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 15.08.2006 15:37:31 von giannici

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

am 04.09.2006 17:02:08 von patg

Federico,

Sorry for the belated reply.

I'll look into this issue and see if indeed the pointer is stale. Do you
have a test script I could use to reproduce this? Another thing you can
also do is use server side prepared statements in the latest driver. It
doesn't use ParseParam (which does the statement parsing). It lets the
server do this work.

Thanks!

Patrick

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/DB I.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.
>

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

am 04.09.2006 17:04:52 von patg

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/DB I.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.
>>
>
>

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

am 04.09.2006 17:04:52 von Patrick Galbraith

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

am 09.09.2006 11:07:43 von Federico Giannici

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/DB I.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@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 09.09.2006 11:07:43 von giannici

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

am 11.09.2006 15:39:20 von Federico Giannici

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/DB I.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@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 11.09.2006 21:50:45 von Sam Smith

On Mon, 11 Sep 2006, Federico Giannici wrote:
> I have seen that version 3.0007 has been released and it (should) have fixed
> that bug.

I'm still seeing segfaults with 3.0007

gdb /usr/bin/perl
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.0"...(no debugging symbols found)

(gdb) target core perl.core
Core was generated by `perl'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libperl.so.10.1...
done.
Loaded symbols for /usr/lib/libperl.so.10.1
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Reading symbols from /usr/lib/libutil.so.11.0...done.
Loaded symbols for /usr/lib/libutil.so.11.0
Reading symbols from /usr/lib/libc.so.39.2...done.
Loaded symbols for /usr/lib/libc.so.39.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so...done.
Loaded symbols for /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so
Reading symbols from /usr/libdata/perl5/i386-openbsd/5.8.8/auto/List/Util/Util.so ...done.
Loaded symbols for /usr/libdata/perl5/i386-openbsd/5.8.8/auto/List/Util/Util.so
Reading symbols from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/HTML/Pa rser/Parser.so...done.
Loaded symbols for /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/HTML/Pa rser/Parser.so
Reading symbols from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mys ql/mysql.so...done.
Loaded symbols for /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mys ql/mysql.so
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.16.0...done.
Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.16.0
Reading symbols from /usr/lib/libz.so.4.1...done.
Loaded symbols for /usr/lib/libz.so.4.1
Reading symbols from /usr/lib/libssl.so.11.0...done.
Loaded symbols for /usr/lib/libssl.so.11.0
Reading symbols from /usr/lib/libcrypto.so.13.0...done.
Loaded symbols for /usr/lib/libcrypto.so.13.0
Reading symbols from /usr/libdata/perl5/i386-openbsd/5.8.8/auto/IO/IO.so...done.
Loaded symbols for /usr/libdata/perl5/i386-openbsd/5.8.8/auto/IO/IO.so
Reading symbols from /usr/libdata/perl5/i386-openbsd/5.8.8/auto/Socket/Socket.so. ..done.
Loaded symbols for /usr/libdata/perl5/i386-openbsd/5.8.8/auto/Socket/Socket.so
Reading symbols from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/Compres s/Zlib/Zlib.so...done.
Loaded symbols for /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/Compres s/Zlib/Zlib.so
#0 mysql_st_internal_execute (h=0x80b8463c, statement=0x8109f4d4, attribs=0x0, num_params=0, params=0x0, result=0xcf7ddf18,
svsock=0x7f9b8854, use_mysql_use_result=0) at dbdimp.c:2383
2383 salloc= parse_params(svsock,
(gdb) bt
#0 mysql_st_internal_execute (h=0x80b8463c, statement=0x8109f4d4, attribs=0x0, num_params=0, params=0x0, result=0xcf7ddf18,
svsock=0x7f9b8854, use_mysql_use_result=0) at dbdimp.c:2383
#1 0x0047de9c in XS_DBD__mysql__db_do (cv=0x80b84078) at mysql.xs:458
#2 0x0d2b5465 in XS_DBI_dispatch () from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so
#3 0x0cdd2d08 in Perl_pp_entersub () at /usr/src/gnu/usr.bin/perl/pp_hot.c:2877
#4 0x0cdfd5b9 in Perl_runops_standard () at /usr/src/gnu/usr.bin/perl/run.c:37
#5 0x0cde35df in S_run_body (oldscope=1) at /usr/src/gnu/usr.bin/perl/perl.c:2368
#6 0x0cde3533 in perl_run (my_perl=0x7f47c030) at /usr/src/gnu/usr.bin/perl/perl.c:2285
#7 0x1c0012a6 in main ()
(gdb) [sams@sebastian ~/work/democracy.org.uk/politicalhome]perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=openbsd, osvers=4.0, archname=i386-openbsd
uname='openbsd'
config_args='-dsE -Dopenbsd_distribution=defined'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -fno-delete-null-pointer-checks -pipe -I/usr/local/include',
optimize='-O2',
cppflags='-fno-strict-aliasing -fno-delete-null-pointer-checks -pipe -I/usr/local/include'
ccversion='', gccversion='3.3.5 (propolice)', gccosandvers='openbsd4.0'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E '
libpth=/usr/lib
libs=-lm -lutil -lc
perllibs=-lm -lutil -lc
libc=/usr/lib/libc.a, so=so, useshrplib=true, libperl=libperl.so.10.1
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-R/usr/libdata/perl5/i386-openbsd/5.8.8/CORE'
cccdlflags='-DPIC -fPIC ', lddlflags='-shared -fPIC '

Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
Built under openbsd
@INC:
/usr/libdata/perl5/i386-openbsd/5.8.8
/usr/local/libdata/perl5/i386-openbsd/5.8.8
/usr/libdata/perl5
/usr/local/libdata/perl5
/usr/local/libdata/perl5/site_perl/i386-openbsd
/usr/libdata/perl5/site_perl/i386-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/local/lib/perl5/site_perl
.

Regards
Sam
> 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/DB I.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.
>
>
>

--
Losing: If at first you don't succeed, failure may be your style

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 13.09.2006 18:47:35 von patg

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/DB I.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.
>>>>
>
>

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

am 13.09.2006 18:47:35 von Patrick Galbraith

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

am 13.09.2006 18:49:21 von Patrick Galbraith

Sam Smith wrote:

Sam,

Thanks for the trace. I need to talk to someone about getting an OpenBSD
box to test out potential solutions.

Regards,

Patrick

> On Mon, 11 Sep 2006, Federico Giannici wrote:
>
>> I have seen that version 3.0007 has been released and it (should)
>> have fixed that bug.
>
>
> I'm still seeing segfaults with 3.0007
>
> gdb /usr/bin/perl
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i386-unknown-openbsd4.0"...(no debugging
> symbols found)
>
> (gdb) target core perl.core
> Core was generated by `perl'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libperl.so.10.1...
> done.
> Loaded symbols for /usr/lib/libperl.so.10.1
> Reading symbols from /usr/lib/libm.so.2.3...done.
> Loaded symbols for /usr/lib/libm.so.2.3
> Reading symbols from /usr/lib/libutil.so.11.0...done.
> Loaded symbols for /usr/lib/libutil.so.11.0
> Reading symbols from /usr/lib/libc.so.39.2...done.
> Loaded symbols for /usr/lib/libc.so.39.2
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> Reading symbols from
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so...done.
> Loaded symbols for
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so
> Reading symbols from
> /usr/libdata/perl5/i386-openbsd/5.8.8/auto/List/Util/Util.so ...done.
> Loaded symbols for
> /usr/libdata/perl5/i386-openbsd/5.8.8/auto/List/Util/Util.so
> Reading symbols from
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/HTML/Pa rser/Parser.so...done.
>
> Loaded symbols for
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/HTML/Pa rser/Parser.so
>
> Reading symbols from
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mys ql/mysql.so...done.
>
> Loaded symbols for
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mys ql/mysql.so
> Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.16.0...done.
> Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.16.0
> Reading symbols from /usr/lib/libz.so.4.1...done.
> Loaded symbols for /usr/lib/libz.so.4.1
> Reading symbols from /usr/lib/libssl.so.11.0...done.
> Loaded symbols for /usr/lib/libssl.so.11.0
> Reading symbols from /usr/lib/libcrypto.so.13.0...done.
> Loaded symbols for /usr/lib/libcrypto.so.13.0
> Reading symbols from
> /usr/libdata/perl5/i386-openbsd/5.8.8/auto/IO/IO.so...done.
> Loaded symbols for /usr/libdata/perl5/i386-openbsd/5.8.8/auto/IO/IO.so
> Reading symbols from
> /usr/libdata/perl5/i386-openbsd/5.8.8/auto/Socket/Socket.so. ..done.
> Loaded symbols for
> /usr/libdata/perl5/i386-openbsd/5.8.8/auto/Socket/Socket.so
> Reading symbols from
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/Compres s/Zlib/Zlib.so...done.
>
> Loaded symbols for
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/Compres s/Zlib/Zlib.so
>
> #0 mysql_st_internal_execute (h=0x80b8463c, statement=0x8109f4d4,
> attribs=0x0, num_params=0, params=0x0, result=0xcf7ddf18,
> svsock=0x7f9b8854, use_mysql_use_result=0) at dbdimp.c:2383
> 2383 salloc= parse_params(svsock,
> (gdb) bt
> #0 mysql_st_internal_execute (h=0x80b8463c, statement=0x8109f4d4,
> attribs=0x0, num_params=0, params=0x0, result=0xcf7ddf18,
> svsock=0x7f9b8854, use_mysql_use_result=0) at dbdimp.c:2383
> #1 0x0047de9c in XS_DBD__mysql__db_do (cv=0x80b84078) at mysql.xs:458
> #2 0x0d2b5465 in XS_DBI_dispatch () from
> /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI .so
> #3 0x0cdd2d08 in Perl_pp_entersub () at
> /usr/src/gnu/usr.bin/perl/pp_hot.c:2877
> #4 0x0cdfd5b9 in Perl_runops_standard () at
> /usr/src/gnu/usr.bin/perl/run.c:37
> #5 0x0cde35df in S_run_body (oldscope=1) at
> /usr/src/gnu/usr.bin/perl/perl.c:2368
> #6 0x0cde3533 in perl_run (my_perl=0x7f47c030) at
> /usr/src/gnu/usr.bin/perl/perl.c:2285
> #7 0x1c0012a6 in main ()
> (gdb) [sams@sebastian ~/work/democracy.org.uk/politicalhome]perl -V
> Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
> Platform:
> osname=openbsd, osvers=4.0, archname=i386-openbsd
> uname='openbsd'
> config_args='-dsE -Dopenbsd_distribution=defined'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef
> usemultiplicity=undef
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='cc', ccflags ='-fno-strict-aliasing
> -fno-delete-null-pointer-checks -pipe -I/usr/local/include',
> optimize='-O2',
> cppflags='-fno-strict-aliasing -fno-delete-null-pointer-checks
> -pipe -I/usr/local/include'
> ccversion='', gccversion='3.3.5 (propolice)',
> gccosandvers='openbsd4.0'
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
> alignbytes=4, prototype=define
> Linker and Libraries:
> ld='cc', ldflags ='-Wl,-E '
> libpth=/usr/lib
> libs=-lm -lutil -lc
> perllibs=-lm -lutil -lc
> libc=/usr/lib/libc.a, so=so, useshrplib=true, libperl=libperl.so.10.1
> gnulibc_version=''
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef,
> ccdlflags='-Wl,-R/usr/libdata/perl5/i386-openbsd/5.8.8/CORE'
> cccdlflags='-DPIC -fPIC ', lddlflags='-shared -fPIC '
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
> Built under openbsd
> @INC:
> /usr/libdata/perl5/i386-openbsd/5.8.8
> /usr/local/libdata/perl5/i386-openbsd/5.8.8
> /usr/libdata/perl5
> /usr/local/libdata/perl5
> /usr/local/libdata/perl5/site_perl/i386-openbsd
> /usr/libdata/perl5/site_perl/i386-openbsd
> /usr/local/libdata/perl5/site_perl
> /usr/libdata/perl5/site_perl
> /usr/local/lib/perl5/site_perl
> .
>
>
>
>
>
> Regards
> Sam
>
>> 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/DB I.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.
>>>>>
>>
>>
>>
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 13.09.2006 18:49:21 von patg

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

am 13.09.2006 19:16:17 von Federico Giannici

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/DB I.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@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 13.09.2006 19:16:17 von giannici

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

am 13.09.2006 19:27:45 von Federico Giannici

Patrick Galbraith wrote:
> Sam Smith wrote:
>
> Sam,
>
> Thanks for the trace. I need to talk to someone about getting an OpenBSD
> box to test out potential solutions.

I'm available to test a prerelease version of the DBD driver.

Bye.

--
___________________________________________________
__
|- giannici@neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 13.09.2006 19:27:45 von giannici

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

am 14.09.2006 21:31:51 von Patrick Galbraith

Federico Giannici wrote:

> Patrick Galbraith wrote:
>
>> Sam Smith wrote:
>>
>> Sam,
>>
>> Thanks for the trace. I need to talk to someone about getting an
>> OpenBSD box to test out potential solutions.
>
>
> I'm available to test a prerelease version of the DBD driver.

Thanks!

It's my intent to roll up a release next week with this fix included. Do
you also use the SVN tree for DBD::mysql?

Kind regards,

Patrick

>
>
> Bye.
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

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

am 14.09.2006 21:31:51 von patg