There still does appear to be a problem in firebird running my
application through valgrind, I see the following when connecting to
the database:

==23039==
==23039== Invalid free() / delete / delete[]
==23039== at 0x1B904929: operator delete(void*) (vg_replace_malloc.c:155)
==23039== by 0x1FD9DE10: garbage_collect (vio.cpp:3338)
==23039== by 0x1FD9F179: purge (vio.cpp:4318)
==23039== by 0x1FD9876A: VIO_chase_record_version (vio.cpp:861)
==23039== by 0x1FD9A0EC: VIO_get (vio.cpp:1672)
==23039== by 0x1FEA1E76: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2302)
==23039== by 0x1FEA233F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2567)
==23039== by 0x1FEA0ADF: fetch_left(tdbb*, Rsb*, irsb*) (rse.cpp:1330)
==23039== by 0x1FEA287F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2772)
==23039== by 0x1FEA0ADF: fetch_left(tdbb*, Rsb*, irsb*) (rse.cpp:1330)
==23039== by 0x1FEA287F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2772)
==23039== by 0x1FEA0ADF: fetch_left(tdbb*, Rsb*, irsb*) (rse.cpp:1330)
==23039== by 0x1FEA287F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2772)
==23039== by 0x1FEA0ADF: fetch_left(tdbb*, Rsb*, irsb*) (rse.cpp:1330)
==23039== by 0x1FEA287F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2772)
==23039== by 0x1FEA0ADF: fetch_left(tdbb*, Rsb*, irsb*) (rse.cpp:1330)
==23039== by 0x1FEA287F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2772)
==23039== by 0x1FEA233F: get_record(tdbb*, Rsb*, Rsb*,
rse_get_mode) (rse.cpp:2567)
==23039== by 0x1FEA3752: open_sort(tdbb*, Rsb*, irsb_sort*,
unsigned long) (rse.cpp:3193)
==23039== by 0x1FE9FFD3: RSE_open(tdbb*, Rsb*) (rse.cpp:691)
==23039== Address 0x201511C0 is 792 bytes inside a block of size 16384 alloc'd
==23039== at 0x1B904298: malloc (vg_replace_malloc.c:130)
==23039== by 0x1FEC93BD:
Firebird::MemoryPool::external_alloc(unsigned) (alloc.cpp:114)
==23039== by 0x1FEC9F34:
Firebird::MemoryPool::internal_alloc(unsigned, short, char*, int)
(alloc.cpp:462)
==23039== by 0x1FEC95C6: Firebird::MemoryPool::allocate(unsigned,
short, char*, int) (alloc.cpp:158)
==23039== by 0x1FD64C94: Firebird::MemoryPool::calloc(unsigned,
short, char*, int) (alloc.h:204)
==23039== by 0x1FE3335C: pool_alloc<16>::operator new(unsigned,
Firebird::MemoryPool&, char*, int) (fb_blk.h:22)
==23039== by 0x1FE32CD5: BlockCache<lls>::newBlock() (block_cache.h:39)
==23039== by 0x1FE327D6: JrdMemoryPool::ALL_push(blk*, lls**) (all.cpp:257)
==23039== by 0x1FE972E0: gen_sort(tdbb*, Opt*, unsigned char*,
unsigned char*, Rsb*, jrd_nod*, unsigned short) (opt.cpp:4941)
==23039== by 0x1FE8F934: OPT_compile(tdbb*, Csb*, rse*, lls*) (opt.cpp:766)
==23039== by 0x1FE534EA: post_rse(tdbb*, Csb*, rse*) (cmp.cpp:5432)
==23039== by 0x1FE52881: pass2(tdbb*, Csb*, jrd_nod*, jrd_nod*)
(cmp.cpp:5015)
==23039== by 0x1FE52129: pass2(tdbb*, Csb*, jrd_nod*, jrd_nod*)
(cmp.cpp:4731)
==23039== by 0x1FE4C63C: CMP_make_request(tdbb*, Csb**) (cmp.cpp:1926)
==23039== by 0x1FE49C07: CMP_compile2(tdbb*, unsigned char*,
unsigned short) (cmp.cpp:572)
==23039== by 0x1FD5D1E1: jrd8_compile_request (jrd.cpp:1700)
==23039== by 0x1FD51BF0: isc_compile_request (why.cpp:1157)
==23039== by 0x1FDAC53E: prepare (dsql.cpp:4459)
==23039== by 0x1FDA7F3D: GDS_DSQL_PREPARE_CPP (dsql.cpp:1464)
==23039== by 0x1FDA6AE1: dsql8_prepare (dsql.cpp:389)

I'm going to have explore more in how my application is being compiled
and how that could be effecting how i'm loading the firebird code...
Basically, I'm writing a component for mozilla's xpcom framework that
is implemented using ibpp library. I'm compiling ibpp as a shared
object and linking firebird to ibpp statically. Then I have my
component code that links to the libibpp.so and loaded dynamically by
xpcom and xpconnect. The files:

libibpp.so (linked to libfbstatic.a)
libsimo_module.so (linked dynamically to libibpp.so)

I'm going to see what happens if I link ibpp statically to my module.

-Todd

On Apr 3, 2005 1:25 PM, Todd Fisher <todd.fisher@...> wrote:
> Ann,
> I think you are right! It does seem to be how I'm compiling my code
> compared to how firebird is compiled. I just recompiled ibpp adding
> the following flags and now my app does not crash:
>
> -p -pipe -MMD -ggdb -Wno-switch
>
> I'll run my app through valgrind and see if there are any more errors.
> If not this is wonderful breakthrough for me :-)
>
> Thank you so much for pointing me in the right direction.
>
> -Todd
>
> On Apr 2, 2005 12:59 PM, Ann W. Harrison <aharrison@...> wrote:
> > Todd Fisher wrote:
> > > I did some more digging into this problem. It looks like the problem
> > > is in getDefaultMemoryPool
> > >
> >
> > Todd,
> >
> > I haven't put much time into your traces etc. but you may have run
> > into a peculiarity of shared code. The calling sequence for the memory
> > allocator is different when compiled for debugging than when compiled
> > without the debugging switches and so mixing modules that were compiled
> > differently will give you that sort of crash.
> >
> >
> > Regards,
> >
> >
> > Ann
> >
> >
> > ________________________________
> > Yahoo! Groups Links
> >
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/firebird-support/
> >
> > To unsubscribe from this group, send an email to:
> > firebird-support-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>