---------- Original Message ----------- From: "unordained" <unordained...@csmaster.org> To: firebird-devel@lists.sourceforge.net Sent: Fri, 15 Jun 2012 10:59:00 -0500 Subject: [Firebird-devel] incomplete crash report
> I'm only setup (sort of) to get stack traces in my test environment, > not production. All I have to offer is the following from the windows > event log: > > Faulting application fbserver.exe, version 2.1.5.18479, time stamp > 0x4f73e2ed, faulting module fbserver.exe, version 2.1.5.18479, time > stamp 0x4f73e2ed, exception code 0xc0000005, fault offset 0x00073f6b, > process id 0x1f60, application start time 0x01cd3edec0abab7a. > > Accompanied by the generic firebird.log entry: > > BTFIPS (Client) Fri Jun 15 04:17:36 2012 > REMOTE INTERFACE/gds__detach: Unsuccesful detach from database. > Uncommitted work may have been lost > > Currently running a nightly build, because you guys were kind enough > to provide much-needed fixes. I saw the RC1 for 2.1.5 is out, I look > forward to upgrading soon. This is SS 32-bit (because of 32-bit UDF's > and my laziness) on Windows Server 2008 x64. The instructions I see > for getting stack-traces all involve Dr. Watson, which isn't available > anymore. I've found other apps, but they're finnicky and only seem > useful to me if I'm diagnosing a reproducible, short- term crash in FB > (I think I've submitted at least one stack-trace from that in the > recent past, it was a known issue, and the reason for switching to the > current build we use?) Do we have updated documentation on capturing > useful crash dumps from W2k8+, on a continuous basis? > > I can tell you that this crash was during a every-morning re-indexing > process. A cron-job first deactivates a good 95% of the indices, > commits, then re- activates them and commits. (We have issues with > night-time jobs that mess with millions of rows, and the indices get > rather less useful by morning, for OLTP use.) > > This job usually succeeds, but every once in a while... FB crashes > (and gets restarted), leaves some indexing deactivated, and then I > discover it around 8am when users start making requests that don't > come back in time and the deadlocks are piling up. I manually re-run > that same job, it succeeds, I restart app- servers, and everyone's > happy. (Yes, I clearly need better error-handling. I'm just not very > good with bash scripts and detecting isql failures so I can deal with > them. I'll get better though.) > > So I can't force it to happen: the job runs most days without problem, > and a second pass after a failure usually succeeds. It's fairly rare -- > once a month or so? > > -Philip ------- End of Original Message ------- Happened again this morning, and I've got a mini-dump this time; who wants it? -Philip ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
