dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file or
directory
I checked a cvs diff between the two timestamps and that's precisely when the
self-adjusting
Gregory Stark [EMAIL PROTECTED] writes:
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
or directory
I checked a cvs diff between the two timestamps
Gregory Stark [EMAIL PROTECTED] writes:
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
or directory
Yeah, I already asked Sergey about this but I guess
Gregory Stark [EMAIL PROTECTED] writes:
And given the consistency and the fact that the other icc machines
didn't show the same problems it sounds like it's something about that
machine, not a software problem.
Well, we haven't *got* any other icc-on-ia64 machines AFAICS, so it
could easily be
On Tue, 2 Oct 2007, Gregory Stark wrote:
(we don't seem to have a recent icc ia32 build farm member).
Sorry about that, my buildfarm member (mongoose) is down with hardware
problems, and probably will be for the forseeable future. For some
reason, it suddenly decided to stop recognizing its
It appears to be getting the wrong address for tsearch()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x011b
0x9009a7c8 in tsearch ()
However if I set a break point for tsearch, I get
br tsearch
Breakpoint 5 at 0xe08c64: file
Dave Cramer [EMAIL PROTECTED] writes:
It appears to be getting the wrong address for tsearch()
I applied a patch for that earlier today. It seems that in OS X 10.4
the compiler generates a function with the same name as the shared
library, ie tsearch() for libtsearch ... and it doesn't tell you
