[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7597: multi-threaded sort can segfault (unrelated to the sort -u seg

From: Paul Eggert
Subject: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)
Date: Thu, 09 Dec 2010 10:26:28 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]