Crash in Firebird::MemoryPool::internal_alloc [CORE1767] #2192
Comments
Modified by: Antti Nivala (nivant)Attachment: M-Files_4_0_1808_0_20080222_133053.dmp [ 10775 ] |
Modified by: Antti Nivala (nivant)Attachment: M-Files_4_0_1808_0_20071005_125143.dmp [ 10776 ] |
Modified by: Antti Nivala (nivant)Attachment: M-Files_4_0_1808_0_20080201_143705.dmp [ 10777 ] |
Modified by: Antti Nivala (nivant)Attachment: Call stack.txt [ 10778 ] |
Modified by: Antti Nivala (nivant)description: We have received three crash dump files from our customers that all point to a crash in Firebird::MemoryPool::internal_alloc, apparently during query preparation. The textual call stack from the crashed thread is attached, as well as the crash dump files that can be easily examined with Visual Studio 2005, for example. The attached MFServer.exe and MFServer.pdb files should be placed in the same folder as the DMP files to ensure that Visual Studio 2005 can load the symbols. However, as far as I can tell, this crash is not related to our software but rather an internal crash of Firebird. If it seems otherwise, just let me know! The actual crash occurs in alloc.cpp, line 1297: // Moderately cheap case. Quite possibly we only need to tweak doubly Here, eax is 1, and the above line leads to the following error: If I am interpreting the disassembly information correctly, then "next_free" pointer has the value 1, which is probably wrong and causes the crash. => We have received three crash dump files from our customers that all point to a crash in Firebird::MemoryPool::internal_alloc, apparently during query preparation. The textual call stack from the crashed thread is attached, as well as the crash dump files that can be easily examined with Visual Studio 2005, for example. If you need MFServer.exe and MFServer.pdb to get the debugger to display the call stacks properly, e-mail me at mailto:antti.nivala@motivesys.com. As far as I can tell, this crash is not related to our software but rather an internal crash of Firebird. If it seems otherwise, just let me know! The actual crash occurs in alloc.cpp, line 1297: // Moderately cheap case. Quite possibly we only need to tweak doubly Here, eax is 1, and the above line leads to the following error: If I am interpreting the disassembly information correctly, then "next_free" pointer has the value 1, which is probably wrong and causes the crash. |
|
Commented by: Sean Leyne (seanleyne) Antti, The current release of v2.0.x is v2.0.3, please use this version, as a number of fixes have been made since v2.0.1 |
|
Commented by: Antti Nivala (nivant) Sean, Yes, we have already switched to using 2.0.3. However, it takes time before all customers have upgraded to the new version, too. We have received these crash dumps from customers that are running Firebird 2.0.1. The problem appears only randomly so we cannot verify whether this does or does not occur with Firebird 2.0.3. We have of course instructed these customers to upgrade to 2.0.3. Is there some specific issue that has been fixed in 2.0.3 that could be related to this problem? |
|
Commented by: @dyemanov There was one memory management related bugfix in v2.0.2, perhaps it could fix that. But it's hard to guess without a test case. |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: Antti Nivala (nivant)
Attachments:
M-Files_4_0_1808_0_20080222_133053.dmp
M-Files_4_0_1808_0_20071005_125143.dmp
M-Files_4_0_1808_0_20080201_143705.dmp
Call stack.txt
We have received three crash dump files from our customers that all point to a crash in Firebird::MemoryPool::internal_alloc, apparently during query preparation. The textual call stack from the crashed thread is attached, as well as the crash dump files that can be easily examined with Visual Studio 2005, for example. If you need MFServer.exe and MFServer.pdb to get the debugger to display the call stacks properly, e-mail me at mailto:antti.nivala@motivesys.com.
As far as I can tell, this crash is not related to our software but rather an internal crash of Firebird. If it seems otherwise, just let me know!
The actual crash occurs in alloc.cpp, line 1297:
// Moderately cheap case. Quite possibly we only need to tweak doubly
// linked lists a little
ptrToBlock(next_free)->mbk_prev_fragment = NULL;
012F2020 mov dword ptr [eax-4],0
Here, eax is 1, and the above line leads to the following error:
"Access violation reading location 0xffffffff"
If I am interpreting the disassembly information correctly, then "next_free" pointer has the value 1, which is probably wrong and causes the crash.
The text was updated successfully, but these errors were encountered: