Subject Re: [Firebird-Architect] Firebird 2.5 built from source code on AIX 6.1 - core dump
Author
In addition to my previous reply:

I've tried to build from a snapshot created a couple of weeks ago, and it core dumped in a different place:

Core was generated by `create_db'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x000000010000ae5c in allocate_nothrow__Q2_8Firebird10MemoryPoolFUlT1PCci (this=0x0, size=<unknown type>,
    upper_size=<unknown type>, file=0x0, line=0) at ../src/common/classes/alloc.cpp:668
668     ../src/common/classes/alloc.cpp: A file or directory in the path name does not exist..
(gdb) where
#0  0x000000010000ae5c in allocate_nothrow__Q2_8Firebird10MemoryPoolFUlT1PCci (this=0x0, size=<unknown type>,
    upper_size=<unknown type>, file=0x0, line=0) at ../src/common/classes/alloc.cpp:668
#1  0x000000010000b3dc in Firebird::MemoryPool::allocate( (unsigned long, char const *, int)) (this=0x0,
    size=<unknown type>, file=0x0, line=0) at ../src/common/classes/alloc.cpp:776
#2  0x000000010000b484 in Firebird::GlobalStorage::operator new( (unsigned long)) (size=<unknown type>)
    at ../src/include/../common/classes/alloc.h:544
#3  0x000000010083ba9c in EDS::RegisterInternalProvider::__ct( (void)) (this=0x1101785d0 <_$STATIC>)
    at ../src/jrd/extds/InternalDS.cpp:57
#4  0x000000010083bd1c in __sinit80000000_x_2fexport_2fhome_2filmbuild_2fTEST_2fFB_2ffirebird_2dcode_2d59478_2fsrc_2fjrd_2fextds_2fInternalDS_2ecpp () at ../src/jrd/extds/InternalDS.cpp:118
#5  0x0900000000b86b04 in __catchThrownException () from /usr/lib/libC.a(shrcore_64.o)
#6  0x0900000000096620 in initialize_one_library () from /usr/lib/libc.a(shr_64.o)
#7  0x0900000000095d48 in grab_orig_libs () from /usr/lib/libc.a(shr_64.o)
#8  0x090000000009483c in __run_initial_ctors () from /usr/lib/libc.a(shr_64.o)
#9  0x000000010000062c in __C_runtime_startup ()
#10 0x09fffffff000362c in usl_exec_init_mods () from /usr/ccs/bin/usla64
#11 0x00000001000002dc in __start ()

Seems to be in early beginning of execution. I don't see anything wrong in ulimit settings:
bash-3.2$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) unlimited
pipe size            (512 bytes, -p) 64
stack size              (kbytes, -s) hard
cpu time               (seconds, -t) unlimited
max user processes              (-u) 500
virtual memory          (kbytes, -v) unlimited

Looks like  FB can't allocate memory, but this box has 64G of it. Disk space shows 4G available.

Any ideas would be appreciated.

Thanks!