bug#9321: repeated segfaults sorting large files in 8.12

[Jim Meyering]

tags 9321 + notabug
close 9321
thanks

Jim Meyering wrote:
> Andras Salamon wrote:
>
>> I am seeing repeated (but not reliably repeatable) segmentation faults
>> sorting datasets in the 100MB-100GB range on a 64-bit Debian system
>> using GNU sort 8.12 (and also 8.9).  Stack traces seem to indicate
>> problems during the merge phase, usually when the temporary files
>> are being combined.
>>
>> This may or may not be related to the recent discussion about
>> #9307, but I am definitely using 8.12, rebuilt with CFLAGS=-g since
>> several indicative values were otherwise optimised out, configured
>> with --disable-nls --disable-threads, and am running with a fixed
>> buffer -S 100M and also --parallel=1 to try to isolate problems from
>> possible threading issues.  I was seeing these crashes with a vanilla
>> build also.
>>
>> At least one crash occurred when comparing the very last entry in
>> the memory buffer to a non-existent entry, when merging large files.
>>
>> There was also a crash with total_lines=851122 in mergelines_node,
>> which leads to node->hi containing what appears to be garbage, with
>> length=2882303761517117516.
>>
>> The repository changelog seems to indicate that the current development
>> release of sort has not changed since 8.12.  Will attempting to track
>> the problem down with 8.12 be useful?
>
> Yes, most definitely.
> As Pádraig already mentioned, most useful would be instructions
> showing how to reproduce the failure, even if part of that is something
> like "run this command 30 times" to provoke the rare failure.
>
>> If so I can post stack traces
>> and values of relevant variables from the core dump, or post a new
>> issue in the tracker, or reopen #9307.  If not, please suggest some
>> specific actions I should take to generate useful information.
>
> Thanks for the detailed report and investigation.
> Have you reproduced the problem on more than one system?
> If not, have you recently run any tests of your system's hardware?
> It would be a shame to invest a lot of debugging effort,
> if it ends up being a hardware problem with one specific system.

Per http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1527/focus=1551
I'm closing this.