Re: gsort problem (TAKE 2)

[Paul Eggert]

"Anthony Tiemens" <address@hidden> writes:

> re Valgrind, appears that I cannot use this as I am on HP-UX!

Do you have a commercial equivalent installed?
E.g., Purify, or something in an HP-supplied development environment,
or perhaps one of the other debuggers listed in
<http://en.wikipedia.org/wiki/Memory_debugger>?  I wouldn't suggest
purchasing one, but if you've already got one you should use it.

At the point of failure, can you print the contents of the
merge_buffer_size variable?  That might be visible to GDB even if you
haven't compiled with -g.

I ran sort (GNU coreutils) 5.96 on an artificial test case designed to
mimic your data somewhat, but did not reproduce the problem on my host
(Debian GNU/Linux 3.1 x86).  You can reproduce my test case by running
the following script (you may need to use nawk or GNU awk because
ordinary HP-UX awk might not handle such large files).

#! /bin/sh
awk 'BEGIN {
  for (i = 0; i < 76695844; i++)
    print i, 
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}' </dev/null >big

This should create a file named 'big' that contains 10,572,915,362
bytes.  Perhaps you can try sorting the file 'big' on your host.  If
it sorts correctly, then this isn't a good test case to find the
problem (can you suggest a better test case?).  If it doesn't sort
correctly, then it's a porting bug or incompatibility of some sort,
that we need to track down, e.g., by compiling 'sort' with -g and then
debugging it.