"Anthony Tiemens" <[EMAIL PROTECTED]> writes:
>HERE'S MY BACKTRACE...
> (gdb) ba
> #0 0x125b8 in xalloc_die+0x18 ()
> #1 0x19244 in xnrealloc_inline+0x7c ()
> #2 0x19298 in xrealloc+0x30 ()
> #3 0x193e0 in x2nrealloc_inline+0xd0 ()
> #4 0x19430 in x2realloc+0x30 ()
> #5 0xd4b4 in fil
Anthony Tiemens would like to recall the message, "gsort problem".
This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have received
this e-mail in error, please notify the sender and delete this e-mail
immedi
please ignore last email...
I inserted my backtrace after yours further down
Anthony
-Original Message-
From: Paul Eggert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 7 June 2006 3:33 PM
To: Anthony Tiemens
Cc: bug-coreutils@gnu.org
Subject: Re: gsort problem
"Anthony Tiemens" <[EMAIL P
/CML/medw/tmp/orasupptest_gsort> gdb ./gsort-HPUX-6.6.6
HP gdb 3.1 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 3.1 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the condition
I installed the following in coreutils HEAD so that 'expr' detects and
reports integer overflow. Formerly, 'expr' silently ignored integer
overflow, typically wrapping around, which is not a good idea in
general and in a few cases (x86 division, I suspect) meant that 'expr'
might dump core.
It's
"Anthony Tiemens" <[EMAIL PROTECTED]> writes:
> when I test it with a 10gig file, it fails with a "memory exhausted"
> error. The unix admin has investigated and monitored the
> environment during the execution and appears there is plenty of
> memory etc.
>
> Any ideas what could cause this? Is i
"Steve Chamberlin" <[EMAIL PROTECTED]> writes:
> My preference for the sort is to default to the standard ASCII
> collating sequence
On my host "sort --help" says:
*** WARNING ***
The locale specified by the environment affects sort order.
Set LC_ALL=C to get the traditional sort order that uses
Hello all,
My name is Steve Chamberlin and I currently work for Qsent in
Beaverton, OR. I have been using the sort utility version 5.2.1 in LINUX
and seem to be having a problem with special characters. If a line
contains these characters, essentially anything beyond numbers and
letters, they do
Could you please try this patch?
http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00160.html
It should appear in the next coreutils version, but I'd like to verify
that it works for you. That patch does work on HP-UX 11.11 but as far
as I know nobody has checked it on Fedora Core.
Tha
Bob and Tim,
Sorry this waited so long, but I had to work-around the issue and didn't get
back to checking it out.
I checked all the ulimit suggestions and all said unlimited. As I burn DVD iso's
from this machine, I regularly generate > 2GB files with no difficulty.
I copied a version of sort fr
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
[...]
RW> Automake patch:
RW> * m4/depout.m4 (_AM_OUTPUT_DEPENDENCY_COMMANDS): Do not use
RW> plain `grep' on the Makefile, as its line length may exceed that
RW> for grep. Bug report against coreutils by Sam Sirlin.
Please install!
[
11 matches
Mail list logo
