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/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) [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/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.
>>>>>
>>
>>
>>
>
