Bug#663016: [synaptic] Segmentation fault after upgrade to 0.75.5
Hi, On 03/08/2012 09:16 AM, Michael Vogt wrote: syslog shows: Mar 8 01:31:18 linprofs-hgb kernel: [ 8440.806485] synaptic[7794]: segfault at 0 ip 0047ec41 sp 7fffab0cd3d0 error 4 in synaptic[40+b7000] Thanks for looking at it. Could you please run synpatic under gdb ? To do that, you need to install it first and then run: $ sudo gdb synaptic (gdb) run [wait for crash] (gdb) backtrace full and send me the output? here you are: GNU gdb (GDB) 7.4-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/sbin/synaptic...(no debugging symbols found)...done. (gdb) run Starting program: /usr/sbin/synaptic [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. 0x0047ec41 in ?? () (gdb) backtrace full #0 0x0047ec41 in ?? () No symbol table info available. #1 0x0047a7da in ?? () No symbol table info available. #2 0x0046c362 in ?? () No symbol table info available. #3 0x00417499 in ?? () No symbol table info available. #4 0x73323ead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #5 0x00419ef1 in ?? () No symbol table info available. #6 0x7fffe6f8 in ?? () No symbol table info available. #7 0x001c in ?? () No symbol table info available. #8 0x0001 in ?? () No symbol table info available. #9 0x7fffe925 in ?? () No symbol table info available. #10 0x in ?? () No symbol table info available. (gdb) -- hgb -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663016: [synaptic] Segmentation fault after upgrade to 0.75.5
Hi Michael,
On 03/08/2012 09:43 AM, Michael Vogt wrote:
Thanks, unfortunately this is very little information :/
Would it be possible for you to do a debug build? It goes like this:
$ sudo apt-get build-dep synaptic
$ sudo apt-get source synaptic
$ cd synaptic-0.75.5
$ DEB_BUILD_OPTIONS=nostrip noopt dpkg-buildpackage
This should give you a deb package that contains more debug
information to help finding the crash with gdb.
I hope this helps (wrong quoting, I know *sigh*):
(gdb) run
Starting program: /usr/sbin/synaptic
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Program received signal SIGSEGV, Segmentation fault.
0x0047ec41 in RPackageViewOrigin::addPackage (this=0x776e80,
package=0xeaffc0) at rpackageview.cc:614
614 if(strcmp(VF.File().Archive(), now) == 0)
(gdb) backtrace full
#0 0x0047ec41 in RPackageViewOrigin::addPackage (this=0x776e80,
package=0xeaffc0) at rpackageview.cc:614
VF = {pkgCache::IteratorpkgCache::VerFile,
pkgCache::VerFileIterator = {std::iteratorstd::forward_iterator_tag,
pkgCache::VerFile, long, pkgCache::VerFile*, pkgCache::VerFile = {No data
fields}, _vptr.Iterator = 0x49ed90, S = 0x7fffed8514f8,
Owner = 0x943c00}, No data fields}
prefix = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x186b9c8 Not automatic: }}
origin_url = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x1866298 ftp.debian.nl}}
subview = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x187e6e8 Not automatic: unstable(ftp.debian.nl)}}
suite = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x1867378 unstable}}
Ver = {pkgCache::IteratorpkgCache::Version, pkgCache::VerIterator
= {std::iteratorstd::forward_iterator_tag, pkgCache::Version, long,
pkgCache::Version*, pkgCache::Version = {No data fields}, _vptr.Iterator
= 0x49edd0, S = 0x7fffed8462f0,
Owner = 0x943c00}, No data fields}
subview = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x18766c8 stable/main (ftp.debian.nl)}}
component = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x187eb68 main}}
origin_url = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x1864e78 ftp.debian.nl}}
origin_str = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x186c018 Debian}}
suite = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x1866028 stable}}
#1 0x0047a7da in RPackageView::refresh (this=0x776e80) at
rpackageview.cc:90
i = optimized out
#2 0x0046c362 in RPackageLister::openCache (this=0x776a00) at
rpackagelister.cc:421
---Type return to continue, or q return to quit---
i = optimized out
lock = optimized out
deps = 0x942400
pkgName = {static npos = optimized out,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x18636c8 libpng12-dev}}
count = 40613
firstRun = true
packageCount = optimized out
showAllMultiArch = false
pkgmap = {_M_t = {
_M_impl =
{std::allocatorstd::_Rb_tree_nodestd::pairstd::basic_stringchar,
std::char_traitschar, std::allocatorchar const, RPackage* =
{__gnu_cxx::new_allocatorstd::_Rb_tree_nodestd::pairstd::basic_stringchar,
std::char_traitschar, std::allocatorchar const, RPackage* = {No
data fields}, No data fields},
_M_key_compare = {std::binary_functionstd::basic_stringchar,
std::char_traitschar, std::allocatorchar , std::basic_stringchar,
std::char_traitschar, std::allocatorchar , bool = {No data fields},
No data fields}, _M_header = {
_M_color = std::_S_red, _M_parent = 0xb948b0, _M_left =
0xebe690, _M_right = 0xc5b430}, _M_node_count = 40613}}}
Bug#600578: More descriptions about this problem
Hi, more reports about this problem can be seen within bug #601084 Regards -- hgb -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535238: [usbmount] Partitions of USB-disk mounted to same mountpoint
Hi, On Fri, 2009-07-31 at 15:26 -0300, Rogério Brito wrote: [...] My USB-disk (not flash) has two partitions: 1. vfat 2. ext3. Both partitions are recognized and have no errors. Right. It is strange, but I had a problem quite similar to this one with some udev versions, but I can't reproduce the problem anymore (I'm using sid here, with, perhaps, some updated udev). Can you still reproduce things with udev + usbmount from sid? I am using sid already and there're no new versions of udev available other than 0.141-1 ... When the disk is connected, it is recognized and usbmount mounts them with correct FS types, but both partitions on the exact same location (/media/usb0): excerpt from /var/log/syslog Jul 1 00:55:06 sokrates usbmount[21916]: mountpoint /media/usb0 is available for /dev/sdb2 Jul 1 00:55:06 sokrates usbmount[21920]: mountpoint /media/usb0 is available for /dev/sdb1 end excerpt from /var/log/syslog It seems that usbmount is in a race when checking the available mountpoint and find it both times available ... it's just a matter of luck which partition is mounted first. This might lead to data loss, since a standard user might not recognize that there is such problem. Yes, it seems that there is some race condition somewhere and I will try to check with lockfile-progs what can be done. There're also no new version of lockfile-progs other than 0.1.13 ... I tried with usbmount 0.0.14-1 which I found in svn and the disk is mounted fine: excerpt from /var/log/syslog Aug 5 16:12:51 sokrates kernel: [1807358.676659] sdb: sdb1 sdb2 Aug 5 16:12:51 sokrates kernel: [1807358.723532] sd 16:0:0:0: [sdb] Attached SCSI disk Aug 5 16:12:51 sokrates kernel: [1807358.724131] sd 16:0:0:0: Attached scsi generic sg1 type 0 Aug 5 16:12:52 sokrates usbmount[5130]: executing command: mount -tvfat -osync,noexec,nodev,noatime /dev/sdb1 /media/usb0 Aug 5 16:12:52 sokrates usbmount[5130]: executing command: run-parts /etc/usbmount/mount.d Aug 5 16:12:57 sokrates usbmount[5129]: executing command: mount -text3 -osync,noexec,nodev,noatime /dev/sdb2 /media/usb1 Aug 5 16:12:57 sokrates kernel: [1807365.256657] kjournald starting. Commit interval 5 seconds Aug 5 16:12:57 sokrates kernel: [1807365.256657] EXT3 FS on sdb2, internal journal Aug 5 16:12:57 sokrates kernel: [1807365.256657] EXT3-fs: mounted filesystem with ordered data mode. Aug 5 16:12:57 sokrates usbmount[5129]: executing command: run-parts /etc/usbmount/mount.d end excerpt from /var/log/syslog I believe that 0.0.14-1 seem to work fine, since it doesn't try to lock (or doesn't show it); with this there is a difference of +/- 5 seconds between the two mounts, while 0.0.17 does it at the same second. Unfortunately I don't have enough time left (yet) to go deeper in this and check it; for now I'll pin usbmount to 0.0.14-1 ... Thanks for your bugreport, Rogério Brito. P.S.: Just out of curiosity, which program do you use to report bugs? I see it is different from what my reportbug program uses to list the packages dependencies... reportbug-ng 1.5 from sid. Regards -- hgb signature.asc Description: This is a digitally signed message part
Bug#535238: [usbmount] Partitions of USB-disk mounted to same mountpoint
Package: usbmount Version: 0.0.17 Severity: serious Hi there, I didn't use my USB-disk for two or three months now, but I know that I never had any trouble ... in the meantime usbmount 0.0.17 came out and I believe there is where the trouble starts. Unfortunately usbmount 0.0.16 isn't available anymore in debian repositories, so I cannot doublecheck if it works with that. My USB-disk (not flash) has two partitions: 1. vfat 2. ext3. Both partitions are recognized and have no errors. When the disk is connected, it is recognized and usbmount mounts them with correct FS types, but both partitions on the exact same location (/media/usb0): excerpt from /var/log/syslog Jul 1 00:55:05 sokrates kernel: [440465.213768] sdb: sdb1 sdb2 Jul 1 00:55:05 sokrates kernel: [440465.265885] sd 6:0:0:0: [sdb] Attached SCSI disk Jul 1 00:55:05 sokrates kernel: [440465.266074] sd 6:0:0:0: Attached scsi generic sg1 type 0 Jul 1 00:55:05 sokrates usbmount[21891]: trying to acquire lock /var/run/usbmount/.mount-dev-sdb.lock Jul 1 00:55:05 sokrates usbmount[21891]: acquired lock /var/run/usbmount/.mount-dev-sdb.lock Jul 1 00:55:05 sokrates usbmount[21891]: testing whether /dev/sdb is readable Jul 1 00:55:05 sokrates usbmount[21891]: /dev/sdb does not contain a filesystem or disklabel Jul 1 00:55:06 sokrates usbmount[21916]: trying to acquire lock /var/run/usbmount/.mount-dev-sdb2.lock Jul 1 00:55:06 sokrates usbmount[21920]: trying to acquire lock /var/run/usbmount/.mount-dev-sdb1.lock Jul 1 00:55:06 sokrates usbmount[21916]: acquired lock /var/run/usbmount/.mount-dev-sdb2.lock Jul 1 00:55:06 sokrates usbmount[21916]: testing whether /dev/sdb2 is readable Jul 1 00:55:06 sokrates usbmount[21920]: acquired lock /var/run/usbmount/.mount-dev-sdb1.lock Jul 1 00:55:06 sokrates usbmount[21920]: testing whether /dev/sdb1 is readable Jul 1 00:55:06 sokrates usbmount[21916]: /dev/sdb2 contains a filesystem or disklabel Jul 1 00:55:06 sokrates usbmount[21920]: /dev/sdb1 contains a filesystem or disklabel Jul 1 00:55:06 sokrates usbmount[21916]: /dev/sdb2 contains filesystem type ext3 Jul 1 00:55:06 sokrates usbmount[21916]: mountpoint /media/usb0 is available for /dev/sdb2 Jul 1 00:55:06 sokrates usbmount[21916]: executing command: mount -text3 -onoexec,nodev,noatime /dev/sdb2 /media/usb0 Jul 1 00:55:06 sokrates usbmount[21920]: /dev/sdb1 contains filesystem type vfat Jul 1 00:55:06 sokrates usbmount[21920]: mountpoint /media/usb0 is available for /dev/sdb1 Jul 1 00:55:06 sokrates usbmount[21920]: executing command: mount -tvfat -onoexec,nodev,noatime /dev/sdb1 /media/usb0 Jul 1 00:55:06 sokrates kernel: [440466.513924] kjournald starting. Commit interval 5 seconds Jul 1 00:55:06 sokrates kernel: [440466.519001] EXT3 FS on sdb2, internal journal Jul 1 00:55:06 sokrates kernel: [440466.519044] EXT3-fs: recovery complete. Jul 1 00:55:06 sokrates kernel: [440466.519260] EXT3-fs: mounted filesystem with ordered data mode. Jul 1 00:55:06 sokrates usbmount[21916]: executing command: run-parts /etc/usbmount/mount.d Jul 1 00:55:06 sokrates usbmount[21920]: executing command: run-parts /etc/usbmount/mount.d end excerpt from /var/log/syslog some commands $ mount | grep usb none on /proc/bus/usb type usbfs (rw,nosuid,nodev,devgid=1004,devmode=664) /dev/sdb1 on /media/usb0 type vfat (rw,noexec,nodev,noatime) /dev/sdb2 on /media/usb0 type ext3 (rw,noexec,nodev,noatime) # umount /dev/sdb1 umount: cannot umount /dev/sdb1 -- /dev/sdb2 is mounted over it on the same point. some commands It seems that usbmount is in a race when checking the available mountpoint and find it both times available ... it's just a matter of luck which partition is mounted first. This might lead to data loss, since a standard user might not recognize that there is such problem. Regards Hans-Georg Bork PS: It might be possible that the bug lies within udev which starts usbmount simultaneous. If this is true, please forward to them. --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-3-sokrates.home Debian Release: squeeze/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.de.debian.org 500 testing ftp.be.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== udev | 0.141-1 lockfile-progs| 0.1.13 Package's Recommends field is empty. Package's Suggests field is empty. signature.asc Description: This is a digitally signed message part
Bug#524523: [eog] Latest version for i386 not installable
Package: eog Version: 2.24.3.1-1+b1 Severity: critical --- Please enter the report below this line. --- Hi, the latest version of eog is not installable since the package libgnome-desktop-2-7 does not exist ... the dependency should probably be changed into libgnome-desktop-2-11 or back to the previous libgnome-desktop-2. Thx HG --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-3-sokrates.home Debian Release: squeeze/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.nl.debian.org 500 unstableftp.de.debian.org 500 testing ftp.nl.debian.org --- Package information. --- Depends (Version) == libart-2.0-2 (= 2.3.18) libc6 (= 2.3.6-6~) libcairo2 (= 1.2.4) libdbus-glib-1-2 (= 0.78) libexempi3 (= 2.1.0) libexif12 libgconf2-4 (= 2.23.2) libglade2-0 (= 1:2.6.1) libglib2.0-0 (= 2.16.0) libgnome-desktop-2-7 libgnome2-0 (= 2.17.3) libgnomeui-0 (= 2.22.0) libgtk2.0-0 (= 2.14.0) libjpeg62 liblcms1 (= 1.15-1) libx11-6 libxml2 (= 2.6.27) python2.5 (= 2.5) zlib1g (= 1:1.2.2) gconf2 (= 2.10.1-2) gnome-icon-theme (= 2.19.1) shared-mime-info (= 0.20) signature.asc Description: This is a digitally signed message part
Bug#480426: [gosa] not useable on sid
Package: gosa Version: 2.5.15-2 Severity: serious --- Please enter the report below this line. --- After installation the setup wizard started normally, but at the installation check I get (among other warnings) this message: -- SAMBA password hash generation Error In order to use SAMBA 2/3 you've to install additional perl libraries. Take a look at mkntpasswd. GOsa will NOT run without fixing this. -- Checked mkntpasswd, perl needs Crypt::SmbHash (.deb package unknown to me) and cpan shows Crypt::SmbHash is up to date (0.12) There's nowhere any description which additional libraries are needed here. BTW: php5-snmp 5.2.5-3 is installed, but setup shows that it's not there. Regards -- hgb --- System information. --- Architecture: i386 Kernel: Linux 2.6.22.sokrates.home Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.de.debian.org --- Package information. --- Depends(Version) | Installed -+- php5 | 5.2.5-3 apache2 | exim4| OR mail-transport-agent | php5-gd | 5.2.5-3 php5-imap| 5.2.5-3 php5-ldap| 5.2.5-3 php5-mhash | 5.2.5-3 php5-mysql | 5.2.5-3 php5-imagick | OR imagemagick (= 5.4.4.5-1) | 7:6.3.7.9.dfsg1-2+b2 OR graphicsmagick-im-compat | fping| 2.4b2-to-ipv6-15 libcrypt-smbhash-perl| 0.12-2 smarty | 2.6.19-1 php5-recode | 5.2.5-3 wwwconfig-common | 0.1.1 smarty-gettext | 1.0b1-2 signature.asc Description: This is a digitally signed message part
Bug#444428: libwnck-common replaces libwnck1, but does not provide it
Package: libwnck-common Version: 2.20.0-1 Severity: critical --- Please enter the report below this line. --- Package conflicts and replaces libwnck1 (= 0.10-1), but does not provide it, so that all packages depending on it are going to be deinstalled ore are broken. # apt-get install libwnck-common Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED anjuta devhelp gnome-applets gnome-system-monitor libdevhelp-1-0 libwnck18 notification-daemon The following packages will be upgraded: libwnck-common 1 upgraded, 0 newly installed, 7 to remove and 1 not upgraded. Need to get 254kB of archives. After unpacking 11.5MB disk space will be freed. Do you want to continue [Y/n]? n Abort. Kind regards -- hgb --- System information. --- Architecture: i386 Kernel: Linux 2.6.22.sokrates.home Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.nl.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== | signature.asc Description: This is a digitally signed message part
Bug#442165: apt-spy: Destroys sources.list file
Hi Jeff, I believe that there is still a file called /etc/apt/sources.list.bak created by apt-spy; at least I have it on my system (sid with apt-spy 3.1-16). Fort the remainder I think you're by suggesting something like a tempfile in which all new source lines are written and only copied over (or appended) to sources.list (after a backup) if apt-spy was successful. Kind regards -- hgb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
