RE: gsort problem (TAKE 2)

to makesure it was ok, sort ran ok. thanks for your help, Anthony -Original Message- From: Paul Eggert [mailto:[EMAIL PROTECTED] Sent: Friday, 9 June 2006 3:49 PM To: Anthony Tiemens Cc: bug-coreutils@gnu.org Subject: Re: gsort problem (TAKE 2) "Anthony Tiemens" <[EMAIL PR

Re: gsort problem (TAKE 2)

Paul Eggert <[EMAIL PROTECTED]> wrote: ... >> (gdb) print merge_buffer_size >> $1 = 185835729 > > Wow. That is a huge number. It indicates that there is at least one > line of text in your file that is 185 MB long. Or, that there is a > bug in 'sort' or in your compiler or debugger or whatnot. >

Re: gsort problem (TAKE 2)

"Anthony Tiemens" <[EMAIL PROTECTED]> writes: > debug output of binaary created with "-g" compile option. > > /CML/medw/tmp/orasupptest_gsort> gdb ./gsort-HPUX-5.94-6.7.06 > 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-Pa

Re: gsort problem (TAKE 2)

"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

Re: gsort problem (TAKE 2)

"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

RE: gsort problem (TAKE 2)

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&quo

RE: gsort problem

reakpoint 1, 0x125b8 in xalloc_die+0x18 () (gdb) >>>> I got to the same breakpoint! regards, 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

Re: gsort problem

"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

Re: gsort problem

"Anthony Tiemens" <[EMAIL PROTECTED]> writes: > What version of coreutils will the patch be available in? It's in CVS, so barring some unforeseen event it'll be in the next release. > When will it be released? I wouldn't venture to predict that. But you can use the patch yourself in the meanti

RE: gsort problem

Meyering Cc: Simon Wing-Tang; Anthony Tiemens; bug-coreutils@gnu.org Subject: Re: gsort problem >> Thanks for testing it. I installed that patch (enclosed again below) >> into gnulib and the coreutils CVS trunk. Jim, is it OK if I also >> install this into the coreutils b5_

Re: gsort problem

>> Thanks for testing it. I installed that patch (enclosed again below) >> into gnulib and the coreutils CVS trunk. Jim, is it OK if I also >> install this into the coreutils b5_9x branch? > > Yes. Thanks for dealing with that. OK, done. ___ Bug-cor

Re: gsort problem

Paul Eggert <[EMAIL PROTECTED]> wrote: > "Simon Wing-Tang" <[EMAIL PROTECTED]> writes: > >> This time it sorted correctly and created the temporary files over >> 2GB as follows > > Thanks for testing it. I installed that patch (enclosed again below) > into gnulib and the coreutils CVS trunk.

Re: gsort problem

"Simon Wing-Tang" <[EMAIL PROTECTED]> writes: > This time it sorted correctly and created the temporary files over > 2GB as follows Thanks for testing it. I installed that patch (enclosed again below) into gnulib and the coreutils CVS trunk. Jim, is it OK if I also install this into the cor

RE: gsort problem

imon Wing-Tang Cc: bug-coreutils@gnu.org; Anthony Tiemens Subject: Re: gsort problem Does the following patch to lib/tempname.c fix things for you? --- tempname.c.~1.17.~ 2005-09-21 23:05:39.0 -0700 +++ tempname.c 2006-05-23 01:09:20.0 -0700 @@ -66,14 +66,16 @@ #if _LIBC # defin

Re: gsort problem

Does the following patch to lib/tempname.c fix things for you? --- tempname.c.~1.17.~ 2005-09-21 23:05:39.0 -0700 +++ tempname.c 2006-05-23 01:09:20.0 -0700 @@ -66,14 +66,16 @@ #if _LIBC # define struct_stat64 struct stat64 +# define small_open __open +# define large_open __o

RE: gsort problem

Hi All, this was starting to really confuse me so I went back and tried compiling the whole of coreutils, both with and without the change I made ( which is at best a hack ). I logged the output of the make command and then compared the 2 logs. Interestingly enough, there was 1 differ

Re: gsort problem

"Simon Wing-Tang" <[EMAIL PROTECTED]> writes: > Here's the output of "cc -E tempname.c". Thanks. The key lines are here: switch (kind) { case 0 : fd = open (tmpl, 002 | 400 | 0002000 , 400 | 200 ); break; case 1 :

RE: gsort problem

Hi Paul and Bob, I probably should also mention that I'm not a big C programmer, but am getting there. Here's the output of "cc -E tempname.c". I'm not sure if you want the whole lot, it's appended below. On a very quick check of the system header files the only reference I could f

Re: gsort problem

Paul Eggert wrote: > Also, can you please investigate why coreutils is compiling tempname.c > at all? Coreutils does so only if it concludes that the system > mkstemp has stupid limitations (e.g., mkstemp cannot create more than > 26 files from a given template). HP-UX 10.20 had such a problem, b

Re: gsort problem

"Simon Wing-Tang" <[EMAIL PROTECTED]> writes: > I've just completed a test after altering one part of the source > code for tempname.c ( lib/tempname.c ) as follows > Original: ... >271 case __GT_FILE: >272fd = __open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | >

RE: gsort problem

Simon Wing-Tang Senior Systems Engineer IT [EMAIL PROTECTED] Unix Systems CML IT (03) 9635-4208 -Original Message- From: Bob Proulx [mailto:[EMAIL PROTECTED] Sent: Thursday, 6 April 2006 5:36 PM To: Anthony Tiemens Cc: bug-coreutils@gnu.org Subject: Re: gsort problem Anthony Tiemens wrote:

Re: gsort problem

Anthony Tiemens wrote: > My client is using gsort (32bit, HPUX), input file is 10GB. What version of GNU sort are you using? You can find this using the sort --version output. sort --version > gsort fails when writing the output file with the following error > "../../rfx/bin/gsort: writ