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/Parser/Parser.so...done.
Loaded symbols for
/usr/local/libdata/perl5/site_perl/i386-openbsd/auto/HTML/Parser/Parser.so
Reading symbols from
/usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mysql/mysql.so...done.
Loaded symbols for
/usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mysql/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/Compress/Zlib/Zlib.so...done.
Loaded symbols for
/usr/local/libdata/perl5/site_perl/i386-openbsd/auto/Compress/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) [EMAIL PROTECTED] ~/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/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.
