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 00007f5d88066a3a sp > 00007f5d7d974cb8 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 00007f84f52e6a3a sp > 00007f84f299ccb8 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
