I investigated my application crash dump file, and I finally found out that my app has crashed at fwrite()
in the method "LockManager::bug()."
====ll.1651-1655 at Firebird-126.96.36.199351-0\src\lock\lock.cpp, ====
fwrite(m_header, 1, m_header->lhb_used, fd);
I have a hunch that if "LockManager::acquire_shmem()" failed to "attach_shared_file" (l.1149 at lock.cpp), it calls "LockManager::bug()" (l.1150 at lock.cpp).
"LockManager::bug()" referes "m_header->lhb_used" as it shows above.
However, if "LockManager::attach_shared_file()" fails, m_header will be NULL.
The answer for your first question is....
The database file which my application failed to access is "C:\MyAppData\data\2014-06-20.db."
About the second question,
my application works as local system account (NT_Authority\SYSTEM) and
the local system account has NTFS access rights to read/write to the above database file.
Therefore, I certainly have a right permission to access the database and there is no problem related to this.
I think you might misunderstand what I am talking about.
The point I want to describe is that *NULL pointer reference* after "fatal lock manager error"
but not "fatal lock manager error " itself.
My application insert data to the database for every minite.
In addition to this, the data backup application works in the same computer as my application does work.
This is the reason why "Fatal lock manager error: ISC_map_file failed (reattach shared file)" occurred
to the database file (because of the simultaneous access).
So far, Firebird works correctly.
However, after this error-catch, "LockManager::bug()" is called at l.1150 at lock.cpp (Firebird-188.8.131.52351-0),
then an application that uses fbembed.dll always crashes because of NULL pointer reference.
This is what I am pointing out.
Could you see the actual code and review this issue?
I would appriciate if you get a resolution for this problem.