GNU bug report logs - #7597
multi-threaded sort can segfault (unrelated to the sort -u segfault)

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: Chen Guo <chen.guo.0625 <at> gmail.com>, bug-coreutils <at> gnu.org, DJ Lucas <dj <at> linuxfromscratch.org>, coreutils <at> gnu.org
Subject: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)
Date: Thu, 09 Dec 2010 10:26:28 -0800

On 12/09/10 03:31, Jim Meyering wrote:
> The segfault (and other strangeness we've witnessed)
> arises because each "node" struct is stored on the stack,
> and its address ends up being used by another thread after
> the thread that owns the stack in question has been "joined".

Ah, of *course*!

> My solution is to use the heap instead of the stack.

This can be simplified by allocating all the nodes at once,
since the number of nodes is bounded above by the number
of threads.  I'll take a look at this, if nobody else gets
to it first.

I am also still looking at the problem with the compression/decompression
hang.  The code to do subprocesses is busted in more than
one way: it does not always catch failures (nonzero exit status)
in decompression, and it can falsely report
failure even when compression and decompression are
both perfectly OK.  However, I still don't have a handle
on the actual bug that causes the hang.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.