Bug#764130: libdbi1 double free in dbi_shutdown_r
At 2014-10-06 12:43 László Böszörményi was heard to say: Hi Markus, Sebastian experiencing a double free in libdb1. You can read the details in the bug report[1], but I quote it here. -- cut -- I'm seeing a double-free in dbi_shutdown_r which happens after a connection attempt (using dbi_conn_connect) fails and dbi_conn_close was called. I don't have a full reproduction case yet but I think this is related to the fix for #745980. I *assume* that the following happens: - dbi_conn_open adds the new connection to an internal list (using _update_internal_conn_list) - dbi_conn_connect does not touch that list - when calling dbi_conn_close after connect failed (supposedly conn->connection == NULL), the connection is not removed since dbi_conn_close returns early but after freeing the connection object (_update_internal_conn_list would only happen when not returning early) - when calling dbi_shutdown_r, the connection is still in the internal list and another attempt to close the connection is done causing an invalid read and the double-free I think the right fix is to not return early at all in dbi_conn_close but instead guard each single operation by checking if the required fields are set (similar to how it's done in most cases already). Let me know if you need any other information -- I can then try to come up with a small test-case which reproduces the problem. -- cut -- Cheers, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764130 Sebastian, could you please test-drive the current libdbi sources in the git repository? I concur with your analysis, and I've changed dbi_main.c with a supposed fix for this problem, see http://sourceforge.net/p/libdbi/libdbi/ci/cdc447994cf767ae03fa6b0ca663a6b2a89469dd/ Calling disconnect() if there is no connection should do no harm, as the drivers check for the connection anyway. I prefer to run this driver function as drivers might contain additional cleanup code right there. The remaining functions called in dbi_conn_close() should all be safe even if there is no connection. Please let me know if this patch fixes your problem. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759855: refdb: FTBFS: readln.h:25:22: error: redefinition of typedef 'Function' with different type
At 2014-08-30 21:03, Lucas Nussbaum was heard to say: Source: refdb Version: 1.0.2-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20140830 qa-ftbfs Justification: FTBFS on amd64 [...] In file included from refdbib.c:48:0: readln.h:26:30: error: redefinition of typedef 'CPPFunction' with different type typedef rl_completion_func_t CPPFunction; ^ In file included from /usr/include/readline/readline.h:37:0, from readln.h:22, from refdbib.c:48: /usr/include/readline/rltypedefs.h:38:16: note: previous declaration of 'CPPFunction' was here typedef char **CPPFunction () __attribute__ ((deprecated)); ^ Hi, the build problems are caused by changes to the readline API. These problems were fixed in the svn version of RefDB. Please have a look at the commits r785 and r786 which migrate RefDB to the new API. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733330: still there
Mathieu Malaterre writes:
> Control: reopen -1
> Control: found -1 refdb/1.0.1-1
>
> The bug is still there in release 1.0.1:
>
> https://buildd.debian.org/status/fetch.php?pkg=refdb&arch=i386&ver=1.0.1-1&stamp=1391636439
>
> gcc -DPACKAGE_NAME=\"refdb\" -DPACKAGE_TARNAME=\"refdb\"
> -DPACKAGE_VERSION=\"1.0.1\" -DPACKAGE_STRING=\"refdb\ 1.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"refdb\"
> -DVERSION=\"1.0.1\" -D_GNU_SOURCE=1 -DREADLINE42=1 -DHAVE_ICONV=1
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_SOCKLEN_T=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1
> -DHAVE_LIMITS_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_TIME_H=1
> -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1
> -DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void -DHAVE_STRFTIME=1
> -DHAVE_MKFIFO=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1
> -DHAVE_STRCSPN=1 -DHAVE_STRSTR=1 -DHAVE_STRTOLL=1 -DHAVE_ATOLL=1 -I.
> -DSYSCONFDIR=\"/etc/refdb\" -DULLSPEC=\"%llu\" -D_FORTIFY_SOURCE=2 -g
> -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -O2 -c -o risxhandler.o risxhandler.c
> risxhandler.c: In function 'risx_end_handler':
> risxhandler.c:794:7: warning: passing argument 2 of 'iconv' from
> incompatible pointer type [enabled by default]
>if (iconv(ptr_ardata->conv_descriptor, &my_instring, &inlength,
> &my_elvalue, &outlength) == (size_t)(-1)) {
>^
> In file included from risxhandler.c:43:0:
> /usr/include/iconv.h:42:15: note: expected 'char ** __restrict__' but
> argument is of type 'const char **'
> extern size_t iconv (iconv_t __cd, char **__restrict __inbuf,
>^
> In file included from /usr/include/string.h:638:0,
> from risxhandler.c:39:
> In function 'strcpy',
> inlined from 'risx_end_handler' at risxhandler.c:1393:12:
> /usr/include/i386-linux-gnu/bits/string3.h:104:3: warning: call to
> __builtin___memcpy_chk will always overflow destination buffer
> [enabled by default]
>return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
>^
> In function 'strcpy',
> inlined from 'risx_end_handler' at risxhandler.c:1396:12:
> /usr/include/i386-linux-gnu/bits/string3.h:104:3: warning: call to
> __builtin___memcpy_chk will always overflow destination buffer
> [enabled by default]
>return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
>^
>
I've fixed that bug in svn, see revision 781. I've also uploaded an
updated tarball (refdb-1.0.2.tar.gz) to SF.
regards,
Markus
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Am 2014-02-17 15:13, schrieb László Böszörményi: Hi Markus, On Fri, Jan 31, 2014 at 11:20 AM, Markus Hoenicka wrote: Am 2014-01-31 10:48, schrieb László Böszörményi: On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka wrote: Problem is that I'm not aware of similar limits for floats. Do you know where to get this info from at compile time? Attached a sample. Basically those are: FLT_MAX, DBL_MAX and LDBL_MAX. Ah, I see. I'll see if I can come up with a fixed testkit. Any progress? More than two weeks passed. I may just disable those problematic tests as libdbi-drivers itself works as expected. Regards, Laszlo/GCS Hi, there is some progress, but it's not suitable for general use yet. The revised testkit works ok on Debian including valgrind checks but still shows some differences between values returned from the drivers and expected values. This just takes some more time to fix. Problem is that it causes a bus error on FreeBSD which I cannot reproduce using valgrind, and gdb couldn't enlighten me about what is wrong. Therefore I suggest to disable the tests for the time being. As you mentioned, these are not libdbi or libdbi-drivers problems, but testkit problems. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Am 2014-01-31 10:48, schrieb László Böszörményi: On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka wrote: Problem is that I'm not aware of similar limits for floats. Do you know where to get this info from at compile time? Attached a sample. Basically those are: FLT_MAX, DBL_MAX and LDBL_MAX. Laszlo/GCS Ah, I see. I'll see if I can come up with a fixed testkit. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Am 2014-01-31 05:17, schrieb Prach Pongpanich:
On Fri, Jan 31, 2014 at 7:09 AM, wrote:
Prach Pongpanich writes:
[..]
> (Cc:-ing #737126)
>
> That reduced failures, but still remain the issue with "the_float"
and
> "the_double".
>
> Running "libdbi framework test"...
> test_dbi.c:3732: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1]
should
> match [0] at [test_dbi.c] line [3732]
> test_dbi.c:3733: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1]
should
> match [0] at [test_dbi.c] line [3733]
> Running "libdbi framework test"...
> Running "libdbi framework test"...
> Running "libdbi framework test"...
> Completed "libdbi framework test": 397 passes, 2 failures, 0
exceptions.
> make: *** [test-stamp] Error 1
>
Ok, seems we're halfway there. It is certainly worth checking all the
compiler warnings that Laszlo mentioned. But the above mentioned
failures may be related to the way how libdbi converts floating
point numbers to long long values. Prach, could you please run the
test program below and report any compiler warnings as well as the
output on armel?
float2longlong.c
--8<
#include
#include
int main() {
float bigfloat = 3.402823e+38;
long long bigfloat_casted;
bigfloat_casted = (long long)bigfloat;
printf("%lld\n", bigfloat_casted);
exit (0);
}
I've added a big double:
root@raspy-sid:~# gcc -Wall -g fd2ll.c -o fd2ll
root@raspy-sid:~# ./fd2ll
bigfloat2ll = -1
bigdouble2ll = -1
--
Prach
Thanks. I'll have to mull over this a little, but it basically means
that the design of the test program is flawed. The hard-coded expected
return values are not as platform-independent as we figured, because
they may exceed the range of valid numbers on some platforms. One option
is to forgo the hard-coded values and use constants from limits.h like
LLONG_MAX instead, assuming that they are available on all platforms.
We'd then have to create the string representations via snprintf()
instead of hard-coding them. Problem is that I'm not aware of similar
limits for floats. Do you know where to get this info from at compile
time?
regards,
Markus
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Prach Pongpanich writes:
> On Thu, Jan 30, 2014 at 9:16 PM, Markus Hoenicka
> wrote:
> [..]
>
> >> It's got the same result as without "-fsigned-char". :(
> >
> >
> > Ok, maybe this change alone was not sufficient. I went through the changes
> > between the latest 0.8.x release (where things apparently still worked) and
> > 0.9, and I suspect that we need some of the configure magic that was
> > cleaned
> > out before 0.9. Could you please test the appended patches against
> > configure.ac of both libdbi and libdbi-drivers? To fix the problem, we may
> > have to fiddle with both packages at a time.
> >
>
> (Cc:-ing #737126)
>
> That reduced failures, but still remain the issue with "the_float" and
> "the_double".
>
> Running "libdbi framework test"...
> test_dbi.c:3732: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should
> match [0] at [test_dbi.c] line [3732]
> test_dbi.c:3733: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should
> match [0] at [test_dbi.c] line [3733]
> Running "libdbi framework test"...
> Running "libdbi framework test"...
> Running "libdbi framework test"...
> Completed "libdbi framework test": 397 passes, 2 failures, 0 exceptions.
> make: *** [test-stamp] Error 1
>
> --
> Prach
>
Ok, seems we're halfway there. It is certainly worth checking all the
compiler warnings that Laszlo mentioned. But the above mentioned
failures may be related to the way how libdbi converts floating
point numbers to long long values. Prach, could you please run the
test program below and report any compiler warnings as well as the
output on armel?
regards,
Markus
float2longlong.c
--8<
#include
#include
int main() {
float bigfloat = 3.402823e+38;
long long bigfloat_casted;
bigfloat_casted = (long long)bigfloat;
printf("%lld\n", bigfloat_casted);
exit (0);
}
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737126: libdbi-drivers: FTBFS on powerpc (and other architectures), tests failing
Am 2014-01-30 14:41, schrieb Roland Stigge: Source: libdbi-drivers Version: 0.9.0-2 Severity: serious Hi, libdbi-drivers FTBFS on powerpc like this: ... Running "libdbi framework test"... Running "libdbi framework test"... Running "libdbi framework test"... Running "libdbi framework test"... Running "libdbi framework test"... Running "libdbi framework test"... test_dbi.c:3815: unit test failure: sqlite3 -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_string -> [129] should match [-127] at [test_dbi.c] line [3815] Running "libdbi framework test"... test_dbi.c:3724: unit test failure: sqlite3 -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_longlong -> [129] should match [-127] at [test_dbi.c] line [3724] test_dbi.c:3732: unit test failure: sqlite3 -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should match [0] at [test_dbi.c] line [3732] test_dbi.c:3733: unit test failure: sqlite3 -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should match [0] at [test_dbi.c] line [3733] Running "libdbi framework test"... Running "libdbi framework test"... Running "libdbi framework test"... Completed "libdbi framework test": 395 passes, 4 failures, 0 exceptions. make: *** [test-stamp] Error 1 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 ... This worked with previous versions. See also the logs for of the buildds for various other architectures: https://buildd.debian.org/status/package.php?p=libdbi-drivers&suite=sid http://buildd.debian-ports.org/status/package.php?p=libdbi-drivers&suite=sid Roland Thanks for the report. I guess this is related to bug #736656 which we are currently trying to fix. I'll cc you in our off-list communication regarding that bug. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733330:
At 2014-01-26 14:08 Mathieu Malaterre was heard to say: bug is still present in current 1.0.0 release: https://buildd.debian.org/status/fetch.php?pkg=refdb&arch=i386&ver=1.0.0-1&stamp=1390671194 eg: gcc -DPACKAGE_NAME=\"refdb\" -DPACKAGE_TARNAME=\"refdb\" -DPACKAGE_VERSION=\"1.0.0\" -DPACKAGE_STRING=\"refdb\ 1.0.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"refdb\" -DVERSION=\"1.0.0\" -D_GNU_SOURCE=1 -DREADLINE42=1 -DHAVE_ICONV=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SOCKLEN_T=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void -DHAVE_STRFTIME=1 -DHAVE_MKFIFO=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRCSPN=1 -DHAVE_STRSTR=1 -DHAVE_STRTOLL=1 -DHAVE_ATOLL=1 -I. -DSYSCONFDIR=\"/etc/refdb\" -DULLSPEC=\"%llu\" -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O2 -c -o refdbd.o refdbd.c In file included from /usr/include/string.h:638:0, from refdbd.c:31: In function 'strncpy', inlined from 'main' at refdbd.c:1335:15: /usr/include/i386-linux-gnu/bits/string3.h:120:3: warning: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default] return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); Hi, this is a regrettable packaging error. I built the 1.0.0 tarball on a box which lacked the two most recent svn checkins. I've uploaded an 1.0.1 tarball which includes the two fixes from svn. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733330: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default]
Am 2013-12-28 17:10, schrieb Mathieu Malaterre: Package: refdb Severity: serious In function 'strncpy', inlined from 'main' at refdbd.c:1335:15: /usr/include/x86_64-kfreebsd-gnu/bits/string3.h:120:3: warning: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default] return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); ^ ref: https://buildd.debian.org/status/fetch.php?pkg=refdb&arch=kfreebsd-amd64&ver=1.0.0~pre2-3&stamp=1388246765 fixed upstream, see revision 778. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701549: refdb-clients: bashism in /bin/sh script
fixed upstream, see revision 772 -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594607: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
Clint Byrum writes: > I believe all that is needed is to bump 'LIB_CURRENT' in configure.in from 0 > -> 1, and autoreconf. Hi, I hope it's not too late, but I've prepared a 0.8.4 test tarball: http://libdbi.sourceforge.net/downloads/libdbi-0.8.4.tar.gz This isn't officially released yet, but I could do so in no time. Please have a look at the tarball and let me know if this serves your immediate needs. I've used the 0.8.3 sources and changed the following things: - bumped the package version number to 0.8.4 - updated some autotools-related things in configure.in, autogen.sh, and Makefile.am (recent versions need AC_CONFIG_MACRO_DIR set properly, otherwise I wouldn't be able to bootstrap the build on my FreeBSD development box) - LIB_CURRENT=1, LIB_REVISION=0, LIB_AGE=0 - fixed the --disable-docs behaviour of configure (this had been fixed long ago in HEAD) regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594607: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
Clint Byrum was heard to say: On Aug 28, 2010, at 1:49 AM, Thomas Goirand wrote: Markus, it would be great if an 0.8.4 or 0.8.3.1 release arrived with soname bumped. We could just rebuild all of our rdepends, but then anybody who has depended on libdbi0 will break when the new version arrives. I have to apologize for responding only now as I was off for a short vacation last week. I also have to apologize for the incorrect information that I sent to Thomas. I simply forgot about the changes in the constants which indeed may screw up a few things. I won't make any promises, but I'll try and see whether I can whip up a 0.8.4 maintenance release with the updated so information. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#493349: libdbi-drivers: FTBFS in unstable due to utterly wrong lib checks
The upstream maintainers are working on a thorough fix for this problem which will be available in the upcoming 1.0 release. Please see this thread for further information: http://sourceforge.net/mailarchive/forum.php?thread_name=18581.34527.367481.276833%40yeti.mininet&forum_name=libdbi-drivers-devel regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462511: libdbi-drivers: FTBFS: dbd_pgsql.c:106: error: conflicting types for 'pg_encoding_to_char'
Thomas Goirand writes: > > > dbd_pgsql.c:106: error: conflicting types for 'pg_encoding_to_char' > > > /usr/include/postgresql/libpq-fe.h:518: error: previous declaration of > > 'pg_encoding_to_char' was here The function pg_encoding_to_char() has been available in the PostgreSQL client library for ages, but it has not been declared in libpq-fe.h previously. This was apparently changed in the latest PostgreSQL development release by popular demand. The driver code uses its own prototype of this function to avoid build errors, but the prototype accidentally lacked the "const" prefix. This never came to our attention as it didn't cause any problems until now that the latest PostgreSQL version finally properly declares the prototype. The simplest fix is to change the prototype in dbd_pgsql.c. The pg_encoding_to_char() prototype has apparently been stable for several years, so it is unlikely we'll run into the same problem anytime soon. Using the same prototype twice is ok as long as the two definitions do not differ. Otherwise we'd have to use a pretty elaborate test to check for the existence of the prototype in the include file to make the driver compatible with older and newer PostgreSQL versions. I've checked in a fix along these lines in the cvs version, so the next libdbi-drivers release will not be affected by this problem anymore. The two-line diff is appended below for building the 0.8.2 packages. > Markus: if you can't setup a SID machine to be able to have a look, I > can provide you a VPS for the operation. You are in Europe, right? I > think best would be that I give you a VPS in UK if you need it. Please > let me know if you need that or not. > Thanks for offering access, but I believe this is not going to be necessary in this case. regards, Markus dbd_pgsql.c.diff Description: diff fixes incorrect prototype -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de
Bug#309313: mysql driver cannot retrieve data
Luk Claes writes: > Btw, the new version is 0.7.1-3.0.1 > I gave this new version a try and it looks ok to me. I guess you can close this bug. Thanks to you and Steve for fixing this problem in no time. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Luk Claes <[EMAIL PROTECTED]> was heard to say: > > Thanks a lot. While you're at it, did you run "make check" in the > libdbi-drivers > > directory? This should already give a clue as to whether things work or > not. > > Well, I don't think this would reveal anything in this case, but yes it > is run in the build process. > I didn't notice that make check ran when I built the libdbd-mysql package from CVS. make check builds an interactive test tool, so I should have noticed this even if I was sound asleep. make check might fail if it causes a segfault. If it succeeds, inspecting the input and output for the various data types should reveal the original problem if it still persists. In any case, I'll test the new package on the weekend and let you know what happens. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Luk Claes <[EMAIL PROTECTED]> was heard to say: > I'll upload a new version (the only markable difference would be the > dependency on libmysqlclient12) which you can test in the weekend ;-) > Thanks a lot. While you're at it, did you run "make check" in the libdbi-drivers directory? This should already give a clue as to whether things work or not. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Steve Langasek <[EMAIL PROTECTED]> was heard to say: > It's entirely possible that simply doing a proper rebuild of the i386 > binaries against libmysqlclient12 will also fix whatever problem you're > experiencing... > Granted. > > It would be helpful if you would try to rebuild the current source package > as-is, rather than rebuilding from CVS sources, to confirm whether or not > that fixes the problem. It's preferable if this can be fixed *just* by > rebuilding the i386 binaries, instead of by changing the build-dependency to > point to libmysqlclient14, since the former is easier to push into sarge > than the latter. > I can try this on the weekend. However, I also see from the Debian package description that libdbd-mysql asks for libmysqlclient14 on i386, so I may run into trouble trying to force libmysqlclient12 in here. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Luk Claes <[EMAIL PROTECTED]> was heard to say:
> > libdbd-mysql, and everything works smoothly. I was under the layman's
> > impression that if you build against libmysqlclient12-dev and run
> > libmysqlclient14 you may get into trouble, but I may be wrong here.
>
> I don't think that's a problem perse as the binary package isn't
> connected with libmysqlclient12 in any way AFAICT.
>
Well I *think* a suitable way to screw up things is to change the definition of
structures. I didn't check if anything like this has happened between
libmysqlclient12 and libmysqlclient14, but if the package is built with this
struct in libmysqlclient12-dev:
struct STRUCT {
int a;
int b;
};
whereas libmysqlclient14 assumes this structure to read:
struct STRUCT {
int a;
long long z;
int b;
};
then it shouldn't be too hard to achieve weird behaviour.
>
> Can you reproduce this bug on another platform (not i386)?
>
Wish I had another platform! I can only report that things work smoothly on
other operating systems (FreeBSD4.7, FreeBSD5.3, Windows/Cygwin, Solaris, to
name a few) both with the released version that the Debian packages are based
upon as well as with the current CVS version.
regards,
Markus
--
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Steve Langasek <[EMAIL PROTECTED]> was heard to say: > And, indeed libdbd-mysql already links against libmysqlclient14 in sarge and > sid. So then, why are you suggesting a rebuild as a solution to this bug? > I may not be sufficiently familiar with Debian packaging and such. When I checked the original /debian contents in libdbd-mysql (using the diff.gz from the Debian page, as David forgot to check this stuff into cvs), it had libmysqlclient12-dev listed as a build dependency. So I assumed the binary packages were linked against this library. I've changed these dependencies (the cvs version now asks for libmysqlclient14-dev), rebuilt libdbi0 and libdbd-mysql, and everything works smoothly. I was under the layman's impression that if you build against libmysqlclient12-dev and run libmysqlclient14 you may get into trouble, but I may be wrong here. Taken together, all I can say is that the currently available package is broke, and this has been confirmed independently by several users. Rebuilding libdbi and libdbd-mysql from the CVS sources fixes this problem. Please let me know if I can do anything else to debug or fix this. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Steve Langasek <[EMAIL PROTECTED]> was heard to say: > Uh, linking libdbd-mysql against mysqlclient14 is not an option for sarge, > as this is pretty much a guaranteed segfault in a mod_perl environment. > libdbd-mysql != libdbd-mysql-perl I don't think that libdbi0 and libdb-mysql are required for mod_perl. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Hi Luk, Luk Claes writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi > > > Package: libdbd-mysql > > Do you experience this bug on a i386 system? > Yep. > > Building libdbi and libdbi-drivers from CVS source cures both problems. > > Is the CVS source of a different version? > Yes, there were a couple of changes to both libdbi and the libdbd-xx drivers. But I'm quite sure that it is not these source code changes that somehow fixed the problem on Debian. The library and the drivers were tested on various systems at release time, among them David Parker's Debian box. The driver did work for sure at release time. I rather suspect that the driver is incompatible with the current version of libmysqlclient. > > I suggest rebuilding the package using recent versions of libmysqlclient. > > What version do you mean: of the libmysqlclient12 or the > libmysqlclient14 package? > I've been testing things on a box that ran MySQL 4.1, therefore I used the libmysqlclient14 package. The current CVS code contains a lot of functionality related to character encodings. I guess that libmysqlclient12 would not work anyway. I've fixed the stuff in the debian subdirs of both libdbi and libdbi-drivers. If you check out the current CVS version you should be able to build the packages without any hassles on a Debian testing box. However, I did not change the package version numbers as I simply don't know how to do this. Remember that you will need the CVS versions of both libdbi and libdbi-drivers. The current CVS version drivers won't work with the packaged library and vice versa. Please see my orignal post for the relevant package versions. If you have any further questions, please contact me anytime. However, I can access my Debian box only on weekends as it is located elsewhere. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309313: mysql driver cannot retrieve data
Package: libdbd-mysql Version: 0.7.1-3 Severity: grave When running applications built with libdbi0 (0.7.2-1), the pgsql (libdbd-pgsql) and sqlite (libdbd-sqlite) drivers work ok. The mysql driver (this package) is able to connect to databases, but any attempt to retrieve stored data fails with an error code indicating a data type mismatch between the SQL column and the retrieval function. As an example, you cannot retrieve a 4 byte integer from a MySQL column of type INT using the dbi_result_get_long() function. Attempting to insert data into existing tables causes the app to segfault. Building libdbi and libdbi-drivers from CVS source cures both problems. Other relevant versions: mysql-server-4.1: 4.1.11-3 libmysqlclient14: 4.1.11-3 Debian 3.0 testing Linux version 2.4.26-1-k7 ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian 20040401)) libc6-2.3.2.ds1-21 I suggest rebuilding the package using recent versions of libmysqlclient. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
