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_99@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
aurelien@aurel32.net http://www.aurel32.net
Reply to: