[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

On 16/12/10 22:06, Paul Eggert wrote: > On 12/12/10 07:41, Jim Meyering wrote: >> Paul Eggert wrote: >>> There are also some test cases I need to add for the >>> (unrelated) sort-compression bug, which is next on my >>> list of coreutils bugs to look at. >> >> It would be great to fix that for 8.8,

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

On 12/12/10 07:41, Jim Meyering wrote: > Paul Eggert wrote: >> There are also some test cases I need to add for the >> (unrelated) sort-compression bug, which is next on my >> list of coreutils bugs to look at. > > It would be great to fix that for 8.8, too, > but don't worry if you don't get to i

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

My recent patch had a typo in a comment, which I fixed as follows: >From 7e9599422e85be01dfceecf1f38ff2c2952a3f61 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 13 Dec 2010 10:02:06 -0800 Subject: [PATCH] tests: typo fix * tests/misc/sort-stale-thread-mem: Fix typo in comment. --- tests/

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Paul Eggert wrote: > On 12/12/2010 07:41 AM, Jim Meyering wrote: >> That sounds good, assuming it triggers the bug reliably for you. >> I was hoping to find a way to reproduce it without relying on gensort, >> but won't object if you want to do that. > > In my attempts to reproduce the problem, it'

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

On 12/12/2010 07:41 AM, Jim Meyering wrote: > That sounds good, assuming it triggers the bug reliably for you. > I was hoping to find a way to reproduce it without relying on gensort, > but won't object if you want to do that. In my attempts to reproduce the problem, it's pretty flaky. I think it

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Paul Eggert wrote: > Sorry for botching the NEWS and the change log. To help > make amends, how about if I add a test case for that? That would be welcome. Thanks. > I'm thinking of the 2nd test case in > , > namely this one

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Sorry for botching the NEWS and the change log. To help make amends, how about if I add a test case for that? I'm thinking of the 2nd test case in , namely this one: gensort -a 1 > gensort-10k for i in $(seq 2000); do prin

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Paul Eggert wrote: > Thanks, Chen, that was much nicer than what I was writing. > I did some minor cleanups, mostly to do with catching an > unlikely integer overflow that would have made 'sort' crash badly, > and pushed the following set of patches. Thanks for helping, but... Chen's log message

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Thanks, Chen, that was much nicer than what I was writing. I did some minor cleanups, mostly to do with catching an unlikely integer overflow that would have made 'sort' crash badly, and pushed the following set of patches. >From 780831a8602d9cdc22e7dcf44804e9c7183dd944 Mon Sep 17 00:00:00 2001 Fr

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

> +  size_t nlines = (lo_child)? node->parent->nlo : node->parent->nhi; Small change... Remove unnecessary branch and redirection in sortlines: size_t nlines = node->nlo + node->nhi; >From c691813ecbfce60c207960fd8bd327cc7d99fe39 Mon Sep 17 00:00:00 2001 From: Chen Guo Date: Fri, 10 Dec 2010

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Hi Professor Eggert, On Thu, Dec 9, 2010 at 10:26 AM, Paul Eggert wrote: > 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. Got to it first :-) This ap