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
------------------------------------------------------------------------------
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
