Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
control: tag -1 + moreinfo On Sat, Oct 25, 2014 at 12:29:05PM +0100, brian...@shapes.demon.co.uk wrote: Package: libc6 Version: 2.19-11 Severity: grave File: libc Justification: causes non-serious data loss Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Two computers, both amd64 systems, running Jessie (testing), both dist-upgraded 24 Oct 2014. Attempting to copy a substantial dataset from one machine to the other. I have not tried to find the problem from the command line but can reproduce it from either machine using Gnome (Nautilus). * What exactly did you do (or not do) that was effective (or ineffective)? On one machine, (the Server) enable file sharing (via ~/Public in Nautilus) Then expose a substantial quantity of data (0.3TB is enough here) in the Public folder. For example cd ~/Public mount --bind ../Music Music (I have a lot of FLAC-encoded CDs in Music : you may need to substitute a similarly large lump of data. The example dataset has 14000 large files in 600 folders.) On the other machine, (the Client) in Nautilus, mount users shared files on Server hostname display that folder perform operations on e.g. Music. Right-click/Properties exhibits the problem Copy/Paste (to a local folder on the Client - which DOES have enough space) - also exhibits it, but it takes much longer to manifest. This suggests to me that the problem is in handling directory or file stats rather than simply the file sizes themselves. * What was the outcome of this action? The operation runs for a while, then stops (e.g. the Properties window shows file size increasing, but stops at 253GB (or 63GB when the Client and Server machines are interchanged; but always at the same size) dmesg on the Client machine reports: [ 699.677988] pool[1873]: segfault at 0 ip 7f5d88066a3a sp 7f5d7d974cb8 error 4 in libc-2.19.so[7f5d87fe5000+19f000] (on a subsequent run after a dist-upgrade and restart) [ 303.568248] pool[1941]: segfault at 0 ip 7f84f52e6a3a sp 7f84f299ccb8 error 4 in libc-2.19.so[7f84f5265000+19f000] The crash happens because a NULL pointer is passed to strlen(), which is definitely not allowed. It's therefore not a libc bug, but rather a bug in pool. Where does this binary come from? I haven't been able to find it in the Debian archive (but I might have searched wrongly). -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
Processing control commands: tag -1 + moreinfo Bug #766732 [libc6] libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine Added tag(s) moreinfo. -- 766732: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
On Sun, 2014-10-26 at 12:00 +0100, Aurelien Jarno wrote: control: tag -1 + moreinfo dmesg on the Client machine reports: [ 699.677988] pool[1873]: segfault at 0 ip 7f5d88066a3a sp 7f5d7d974cb8 error 4 in libc-2.19.so[7f5d87fe5000+19f000] The crash happens because a NULL pointer is passed to strlen(), which is definitely not allowed. It's therefore not a libc bug, but rather a bug in pool. Where does this binary come from? I haven't been able to find it in the Debian archive (but I might have searched wrongly). Good question. Google pool : segfault leads to among others https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707681 which I believe is unrelated (cameras, USB) but (message #15) also involves pool (pointing vaguely at dbus). Is pool related to thread pools? or https://bbs.archlinux.org/viewtopic.php?pid=1092046 which at least involves Nautilus so may be more closely related. This points at Gnome bug https://bugzilla.gnome.org/show_bug.cgi?id=674659 which at least gives me some hints about running Nautilus under gdb. If I can dig up anything this way I'll update. - Brian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
Processing control commands: reassign -1 nautilus Bug #766732 [libc6] libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine Bug reassigned from package 'libc6' to 'nautilus'. No longer marked as found in versions glibc/2.19-11. Ignoring request to alter fixed versions of bug #766732 to the same values previously set tag -1 - moreinfo Bug #766732 [nautilus] libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine Removed tag(s) moreinfo. -- 766732: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
control: reassign -1 nautilus control: tag -1 - moreinfo On Sun, Oct 26, 2014 at 12:53:40PM +, Brian Drummond wrote: On Sun, 2014-10-26 at 12:00 +0100, Aurelien Jarno wrote: control: tag -1 + moreinfo dmesg on the Client machine reports: [ 699.677988] pool[1873]: segfault at 0 ip 7f5d88066a3a sp 7f5d7d974cb8 error 4 in libc-2.19.so[7f5d87fe5000+19f000] The crash happens because a NULL pointer is passed to strlen(), which is definitely not allowed. It's therefore not a libc bug, but rather a bug in pool. Where does this binary come from? I haven't been able to find it in the Debian archive (but I might have searched wrongly). Good question. Google pool : segfault leads to among others https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707681 which I believe is unrelated (cameras, USB) but (message #15) also involves pool (pointing vaguely at dbus). Is pool related to thread pools? It seems indeed to be related to glib thread pools, looks like they have been created by nautilus. I am reassigning the bug there, don't hesitate to reassign it to the correct package if needed. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766732: libc: Segfault in libc (from process pool) accessing files shared via DAV across ethernet on another machine
Package: libc6 Version: 2.19-11 Severity: grave File: libc Justification: causes non-serious data loss Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Two computers, both amd64 systems, running Jessie (testing), both dist-upgraded 24 Oct 2014. Attempting to copy a substantial dataset from one machine to the other. I have not tried to find the problem from the command line but can reproduce it from either machine using Gnome (Nautilus). * What exactly did you do (or not do) that was effective (or ineffective)? On one machine, (the Server) enable file sharing (via ~/Public in Nautilus) Then expose a substantial quantity of data (0.3TB is enough here) in the Public folder. For example cd ~/Public mount --bind ../Music Music (I have a lot of FLAC-encoded CDs in Music : you may need to substitute a similarly large lump of data. The example dataset has 14000 large files in 600 folders.) On the other machine, (the Client) in Nautilus, mount users shared files on Server hostname display that folder perform operations on e.g. Music. Right-click/Properties exhibits the problem Copy/Paste (to a local folder on the Client - which DOES have enough space) - also exhibits it, but it takes much longer to manifest. This suggests to me that the problem is in handling directory or file stats rather than simply the file sizes themselves. * What was the outcome of this action? The operation runs for a while, then stops (e.g. the Properties window shows file size increasing, but stops at 253GB (or 63GB when the Client and Server machines are interchanged; but always at the same size) dmesg on the Client machine reports: [ 699.677988] pool[1873]: segfault at 0 ip 7f5d88066a3a sp 7f5d7d974cb8 error 4 in libc-2.19.so[7f5d87fe5000+19f000] (on a subsequent run after a dist-upgrade and restart) [ 303.568248] pool[1941]: segfault at 0 ip 7f84f52e6a3a sp 7f84f299ccb8 error 4 in libc-2.19.so[7f84f5265000+19f000] * What outcome did you expect instead? Successful operation without segfault... I have not tried digging more info using gdb : given Gnome is in the way it's not clear to me how one would go about it, e.g. which process to attach the debugger to! *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6:amd64 depends on: ii libgcc1 1:4.9.1-16 libc6:amd64 recommends no packages. Versions of packages libc6:amd64 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc none ii locales2.19-11 -- debconf information: * glibc/restart-services: exim4 cups cron glibc/disable-screensaver: * libraries/restart-without-asking: false glibc/upgrade: true glibc/restart-failed: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
