Here we go,It's probably okay. It's alright to close the fd after the mmap, and it's not really calling mmap twice--it's just the debugger trying to follow the optimized code.
OK, Just my ignorance :-)
Nope--normally one tries to avoid debugging something built with optimizations turned on, but here we are!
Breakpoint 1, parseCollationElements (tag=0x814b6b8 "", startline=15,
status=0xbfffef38) at parse.c:665
665 coll = ucol_openRules(member->u.fString.fChars, member->u.fString.fLength,
(gdb) next
655 UErrorCode intStatus = U_ZERO_ERROR;
(gdb) next
658 int32_t len = 0;
(gdb)
665 coll = ucol_openRules(member->u.fString.fChars, member->u.fString.fLength,
(gdb)
668 if (U_SUCCESS(intStatus) && coll != NULL)
(gdb)
701 warning(line, "%%Collation could not be constructed from CollationElements - check context!");
(gdb) p coll
$1 = (UCollator *) 0x0
(gdb) p intStatus
$2 = U_INTERNAL_PROGRAM_ERROR
Here's another way to maybe track it down: Once you get to your breakpoint do "watch intStatus", and then continue until you see it being set to U_INTERNAL_PROGRAM_ERROR, and get a backtrace. But, I think it will probably just get set by copying it over from another result code somewhere, and so it might require doing that with a few other variable to really track it down. But, it's sounding more like something is just generally messed up.
Thanks again for the help.
JEff
