"Anthony Tiemens" <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
