Hi,

Could someone give me tips on what could be causing a crash in Firebird
Embedded 2.0.1 while reading the contents of a BLOB. We've received
crash dumps from a few customers, all of these dumps pointing to the
same kind of crash (identical call stacks). The platform is Windows XP
SP2, Firebird version in these cases is 2.0.1.

The field being read is a BLOB field that has been defined as follows:

BLOB SUB_TYPE 0 SEGMENT SIZE 80 NOT NULL

Thus, the field should not be NULL. In general, reading the BLOB from
this field succeeds, but in a couple of cases it has caused a crash. Is
there some known circumstances that could cause a crash during BLOB
reading in this place in the code? The call stack from the crashed
thread is as follows (gds32.dll is really fbembed.dll, only renamed):

gds32.dll!Firebird::MemoryPool::internal_alloc(unsigned int size=416,
short type=0) Line 1267 C++
gds32.dll!Firebird::MemoryPool::allocate_nothrow(unsigned int size=408,
short type=0) Line 577 + 0x11 bytes C++
gds32.dll!Firebird::MemoryPool::allocate(unsigned int size=408, short
type=0) Line 735 + 0x10 bytes C++
gds32.dll!Firebird::BePlusTree<Jrd::BlobIndex,unsigned
long,Firebird::MemoryPool,Jrd::BlobIndex,Firebird::DefaultComparator<uns
igned long>,16,750>::add(const Jrd::BlobIndex & item={...}) Line 509 +
0x1c bytes C++
gds32.dll!allocate_blob(Jrd::thread_db * tdbb=0x09f7f234, Jrd::jrd_tra *
transaction=0x042cca68) Line 1701 + 0x27 bytes C++
gds32.dll!BLB_open2(Jrd::thread_db * tdbb=0x09f7f234, Jrd::jrd_tra *
transaction=0x042cca68, const Jrd::bid * blob_id=0x27200d8c, unsigned
short bpb_length=0, const unsigned char * bpb=0x00000000) Line 1111
C++
gds32.dll!jrd8_open_blob2(long * user_status=0x00000000, Jrd::Attachment
* * db_handle=0x0205e630, Jrd::jrd_tra * * tra_handle=0x02eafe90,
Jrd::blb * * blob_handle=0x042cca68, Jrd::bid * blob_id=0x00000000,
unsigned short bpb_length=62340, const unsigned char * bpb=0x00000064)
Line 2840 C++
00000003()
gds32.dll!sch_mutex_unlock(Firebird::Mutex * mtx=0x09f7f384) Line 1071
C++
gds32.dll!open_blob(long * user_status=0x00000000, void * *
db_handle=0x2d6a4a80, void * * tra_handle=0x0f5feacc, void * *
public_blob_handle=0x27200d94, long * blob_id=0x27200d8c, unsigned short
bpb_length=0, const unsigned char * bpb=0x00000000, short proc=11, short
proc2=30) Line 5697 + 0x53 bytes C++
gds32.dll!isc_open_blob2(long * user_status=0x09f7f384, void * *
db_handle=0x2d6a4a80, void * * tra_handle=0x0f5feacc, void * *
blob_handle=0x27200d94, long * blob_id=0x27200d8c, short bpb_length=0,
const unsigned char * bpb=0x00000000) Line 3789 + 0x2b bytes C++
IBProv.dll!45e4d81e()
IBProv.dll!45e0ddae()
IBProv.dll!45e54fa0()
MFServer.exe!SQLHelper::GetBLOBData(ISequentialStream *
pISequentialStream=0x0153ece0, unsigned long * pulLength=0x09f7f4b8,
unsigned char * * ppData=0x09f7f4c4) Line 1928 + 0x16 bytes C++
MFServer.exe!SQLHelper::GetBLOBData(const
CMDynamicAccessorT<ATL::CDynamicParameterAccessor> & acc={...}, unsigned
long ulColumn=1, unsigned long * pulLength=0x09f7f50c, unsigned char * *
ppData=0x09f7f510) Line 1823 + 0x11 bytes C++
MFServer.exe!RPCObjectTypesHelper::GetACLFromResults(CMDynamicAccessorT<
ATL::CDynamicAccessor> & acc={...}, unsigned long ulColumn=1, CM_ACL &
acl={...}) Line 2418 + 0x15 bytes C++
MFServer.exe!RPCObjectTypesHelper::GetObjectTypeItemACL(CDBSession &
dbsess={...}, const CMF_ObjVer & objver={...}, bool
bMustBeRealObjectType=true, CM_ACL & acl={...}) Line 2337 + 0x20 bytes
C++
MFServer.exe!RPCDocumentOperationsHelper::GetACL(CDBSession &
dbsess={...}, const CMF_ObjVer & objver={...}, CM_ACL & acl={...}) Line
6882 + 0x16 bytes C++
MFServer.exe!RPCDocumentOperationsHelper::GetACLsOfMultipleObjects(CDBSe
ssion & dbsess={...}, const CMFSession * pmfsess=0x096f7448, unsigned
long ulObjCount=10, const CMF_ObjVer * pobjvers=0x25dd2b88, bool
bBypassDocVersionExistenceAndVisibilityChecks=false,
RPCServerArray<CMF_ACL> & arrACLs={...}) Line 6938 + 0x22 bytes
C++
MFServer.exe!MF_GetSecurityOfMultipleObjects(void *
IDL_handle=0x26320420, _SESSIONID sessID={...}, unsigned long
ulObjectCount=10, const _MF_ObjVer * pobjvers_=0x25dd2b88, _MF_ACLArray
* pacls_=0x09f7fd18, _MF_MetaDataVersion * pmdver=0x28eb6868, unsigned
long * pulErrorCount=0x28eb6878, _RPCErrorInfo * *
ppErrorValues=0x28eb6888) Line 2018 + 0x2f bytes C++
rpcrt4.dll!_Invoke@12() + 0x30 bytes
rpcrt4.dll!_NdrStubCall2@16() + 0x217 bytes
rpcrt4.dll!_NdrServerCall2@4() + 0x19 bytes
rpcrt4.dll!_DispatchToStubInCNoAvrf@12() + 0x17 bytes
rpcrt4.dll!RPC_INTERFACE::DispatchToStubWorker() + 0xae bytes
rpcrt4.dll!RPC_INTERFACE::DispatchToStub() + 0x4b bytes
rpcrt4.dll!OSF_SCALL::DispatchHelper() + 0x13b bytes
rpcrt4.dll!OSF_SCALL::DispatchRPCCall() + 0x7c bytes
rpcrt4.dll!OSF_SCALL::ProcessReceivedPDU() + 0xc1 bytes
rpcrt4.dll!OSF_SCALL::BeginRpcCall() + 0x99 bytes
rpcrt4.dll!OSF_SCONNECTION::ProcessReceiveComplete() + 0x11e bytes
rpcrt4.dll!ProcessConnectionServerReceivedEvent() + 0x21 bytes
rpcrt4.dll!LOADABLE_TRANSPORT::ProcessIOEvents() + 0x180 bytes
rpcrt4.dll!ProcessIOEventsWrapper() + 0xd bytes
rpcrt4.dll!BaseCachedThreadRoutine() + 0x94 bytes
rpcrt4.dll!ThreadStartRoutine() + 0x1b bytes
kernel32.dll!_BaseThreadStart@8() + 0x34 bytes

MFServer.exe is our module. All seems to be fine there -- we start the
BLOB reading in the usual way. IBProv.dll is the OLE DB provider that
sits between MFServer.exe and Firebird. The actual crash occurs inside
Firebird's code, but I realize that we could be doing something wrong,
or perhaps the BLOB data in the database is simply corrupt. Or what
would be the likely cause for this kind of crash?

Unfortunately, we only have minidumps from these crashes and apparently
they are not reproducable so we cannot examine full information such as
the values of all variables.

Thanks for all help!!

Antti Nivala

---------------------------------

Motive Systems
http://www.motivesys.com
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/