I'm on Server 2008 and seemingly can't use drwatson anymore, so I'm trying to use "DebugDiag", which I'm not familiar with, please excuse the poor stacktrace. The following's from the middle of the crash report.
Function Arg 1 Arg 2 Arg 3 Source msvcr80!memmove+5a 08362d98 08362d9c fffffffc fbserver!Jrd::LocksCache<Jrd::CachedLock>::get+1a8 089df958 089db1fc 089df958 fbserver!Jrd::BtrPageGCLock::disablePageGC+3f 089df958 089db2e4 249fbe71 fbserver!add_node+13a 00000000 089db2e4 089de42c fbserver!BTR_insert+140 089df958 089de414 089de42c fbserver!insert_key+7b 089df958 014b14d4 0903f71c fbserver!IDX_store+16f 089df958 09010494 01306de8 fbserver!store+162 01306de8 08fa2378 00000000 fbserver!looper+eef 089df958 0901000c 00fa3634 fbserver!EXE_start+21b 089df958 0901000c 01306de8 fbserver!execute_triggers+1d6 089df958 014b2468 00000000 fbserver!store+1a2 01306de8 08701e8c 00000000 fbserver!looper+eef 089df958 08dd000c 00d680e0 fbserver!EXE_start+21b 089df958 08dd000c 01306de8 fbserver!execute_triggers+1d6 089df958 010bb5d4 00000000 fbserver!store+d1 01306de8 08af46c8 00000000 fbserver!looper+eef 089df958 08ce8280 00361248 fbserver!execute_looper+56 00000004 249ff561 01306de8 fbserver!EXE_send+2e5 000000ee 08ce8280 08c59f48 fbserver!jrd8_start_and_send+185 089dfd60 002e0ee4 002e42c4 fbserver!isc_start_and_send+cf 089dfd60 08aedf7c 08aedf68 fbserver!execute_request+279 08aedf24 089dfdb8 00000209 fbserver!GDS_DSQL_EXECUTE_CPP+177 089dfd00 089dfdb8 002e0400 fbserver!dsql8_execute+41 089dfd60 089dfdb8 002e0400 fbserver!isc_dsql_execute2_m+d1 00000000 089dfdb8 002e1958 fbserver!rem_port::execute_statement+1a9 0000003f 0000001f 002e4580 fbserver!process_packet2+3bb 002e4bac 002e4580 002e4834 fbserver!process_packet+4b 002e4bac 002e4580 002e4834 fbserver!loopThread+bd 002e4bac 00000000 004040d3 fbserver!ThreadPriorityScheduler::run+10 249ff321 00000000 00000000 fbserver!`anonymous namespace'::threadStart+53 002e02b8 249fc5ce 00000000 msvcr80!_endthreadex+3b 00000000 7797d309 00307a38 msvcr80!_endthreadex+c7 00307a38 089dffd4 77a516c3 kernel32!BaseThreadInitThunk+e 00307a38 93d917c1 00000000 ntdll!__RtlUserThreadStart+23 735b29e1 00307a38 00000000 ntdll!_RtlUserThreadStart+1b 735b29e1 00307a38 00000000 I'll keep the full dump files in case anyone wants them. The situation is as follows: I have a destination database (FB, 3gb) to which I'm migrated data from a source database (Access, 1gb). To do so, I have an app (using jaybird) that reads data from the Access database and dumps it (update- or-insert) into a set of migration tables, which match the source table definitions. I then have triggers (before insert-or-update) on each of those migration tables that take care of shuttling data to their real destinations, based on whether the data's been previously seen (migration is re-run every day, 99% of the data hasn't changed) or is new/modified somehow; extra fields on the migration table keep track of where the data's been sent, with cascade- set-null foreign keys so that if users delete the destination data, the next pass of the migration will notice and re-import; because of the FK/trigger interaction, I have to ensure my triggers don't recurse (from the stacktrace and my debugging, I don't think that's been the case any time recently.) The crash has been happening on this server for several days now, but it doesn't seem to happen consistently in the same spot -- sometimes not even on the same tables. I've stopped pulling in a new version of the source database, and have been running it over and over again -- same source data, but different points of failure. I've tried adding debugging to the triggers and stored procedures themselves, but haven't found any correlation. Sometimes it crashes right after a trigger finishes (last step in the trigger had completed), some presumably it had something to do with serializing the row changes. I usually (but not always) notice a sudden spike in memory usage right before the crash (this is a multi-hour job, and the spike takes a couple seconds), but that could be from the debugging tools reacting to the crash... I know that 2.1.4 "leaks" memory from temporary blobs, but I've been watching the memory usage and it doesn't seem like that's the problem -- yes, memory gets eaten slowly, maybe 30 MB over the hours of the job, not enough to kill the server. If I'm doing something wrong on the user-side, I'm prepared to fix it -- but it's an access violation, not always in the same place, and I'm running out of options to figure out what I could possibly be doing that confuses FB so badly. My only next step at this point is to try switching to FB 2.5 again, to see if it happens to be fixed there. Not really the planned upgrade, but then, it could provide you with some clues, too. Note that I've recently done a full backup/restore on the destination database, no errors, and no effect on the crashing. This doesn't manifest itself during normal OLTP use of the database, only during this heavy-lifting migration job. -Philip ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
