Bug#555325: version 1.3.4 completely unusable
Package: gq Version: 1.3.4-1 Severity: grave Hi all, Same as the first reporter. Just update gq yesterday in sid. it's totaly unusable. I'm trying to connect via ssl, I never find how to successfully do it. ldapsearch is working smoothly, not gq. I can provide some backtrace of gtk backtraces produced under gdb. I confirm that the dn is forget evry time. The port for ssl is not usuable in the old gq in host field I put before : ldaps://10.42.42.1/ and remove the port entry and it was working. Now, triggers a lot's of assert. I have tried with a LANG=C thinking of a problem with utf8 ... but doens't seems to work better. Some time I've got random data in the dn field, making me thinking of a buffer not rightly initialized or something like that. Got no time atm to track this bug deeply. I can help if somebody want to test things. Regards, Benoît. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gq depends on: ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.22.3-1 The GLib library of C routines ii libgnome-keyring0 2.28.1-2 GNOME keyring services library ii libgtk2.0-0 2.18.4-1 The GTK+ graphical user interface ii libldap-2.4-2 2.4.17-2.1 OpenLDAP libraries ii libpango1.0-0 1.26.1-1 Layout and rendering of internatio ii libssl0.9.8 0.9.8k-7 SSL shared libraries ii libxml2 2.7.6.dfsg-1 GNOME XML library gq recommends no packages. gq suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555325: version 1.3.4 completely unusable
Package: gq Version: 1.3.4-1 > > Same as the first reporter. Just update gq yesterday in sid. it's totaly > unusable. > I'm trying to connect via ssl, I never find how to successfully do it. > ldapsearch is working smoothly, not gq. > > I can provide some backtrace of gtk backtraces produced under gdb. > > I confirm that the dn is forget evry time. > The port for ssl is not usuable in the old gq in host field I put before > : > ldaps://10.42.42.1/ and remove the port entry and it was working. > > Now, triggers a lot's of assert. > > I have tried with a LANG=C thinking of a problem with utf8 ... but > doens't seems to work better. > > Some time I've got random data in the dn field, making me thinking of a > buffer not rightly initialized or something like that. I just do a test using valgrind ... invalid read of already free'd memory ... so invalid pointers are there. Backtrace is not really usable ... : (one sample on 11). This happens when opening the preference box, then the local machine one. ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E7D54: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C5EB: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E6A1C: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x53973B7: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C9C8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724DF17: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x54A05AD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x538F972: gtk_propagate_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x5390A4A: gtk_main_do_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x58BC35B: ??? (in /usr/lib/libgdk-x11-2.0.so.0.1800.4) ==367==by 0x76AF139: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2997: ??? (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2E6C: g_main_loop_run (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x5390E46: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x421747: ??? (in /usr/bin/gq) ==367==by 0x8574ABC: (below main) (libc-start.c:222) ==367== Address 0xd412c10 is 0 bytes inside a block of size 35 free'd ==367==at 0x4C21DBC: free (vg_replace_malloc.c:325) ==367==by 0x4380AC: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723D5F8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C7E4: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C94A: g_object_thaw_notify (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x531B9CE: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x531CE4B: gtk_entry_set_text (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x439866: ??? (in /usr/bin/gq) ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==b
Bug#325387: libtool: some options available in documentation are not usable under AMD64
Package: libtool
Version: 1.5.6-6
Severity: normal
Hi,
I found that on AMD64 (I can't test it under other plateform) the
-static and -all-static options are rejected by libtools as
"unrecognized option `-static'"
but libtool --help list them as valid ones ... so what happens ?
regards,
Benoit.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-9-amd64-k8
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages libtool depends on:
ii autotools-dev 20050803.1 Update infrastructure for config.{
ii cpp 4:4.0.1-3 The GNU C preprocessor (cpp)
ii file 4.12-1 Determines file type using "magic"
ii gcc [c-compiler] 4:4.0.1-3 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-9 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.4-7The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.1-5The GNU C compiler
ii libc6-dev [libc-dev] 2.3.5-4GNU C Library: Development Librari
Versions of packages libtool recommends:
ii libltdl3-dev 1.5.6-6A system independent dlopen wrappe
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
