On Sun, Mar 9, 2008 at 10:55 PM, Helen Borrie <helebor@...> wrote:

> Bugchecks occur when the database engine gets into a state that it cannot
> deal with. The production code is set to return a Bugcheck, rather than to
> crash outright and cause a coredump. The engine tries to analyse where and
> how the condition occurs so, if the engine is still running sufficiently to
> perform this analysis, there will be "clues" in the message - a number in
> brackets followed by one or more lines containing a description relating to
> the clue.
>
> In cases like Ahmad's, where a bugcheck occurs and there are no clues, it
> is quite likely that the condition occurred because the Firebird server
> requested more RAM from the OS and it was refused. No RAM == no ability to
> analyse the fault == no clues reported.
>
> If the engine collapses because of insufficient resources, it is not a
> "bug" that can be reproduced and fixed by the Firebird developers. Note
> that, if RAM got exhausted once "out of the blue", it will happen again,
> next time those conditions occur. The fix is to reconfigure the server
> resources so that there will always be enough RAM for the service to
> operate.
>
> You should also check whether another program - such as a filesystem backup
> utility or an anti-virus program - was running. It is extremely important to
> exclude your database files and the server's files from such programs. A
> no-clues bugcheck can occur when such programs lock sectors of your disk
> that Firebird is using. If the host server is Windows, then many of
> Microsoft's internal utilities, such as SystemRestore, do not respect file
> locks that are in use by applications. Some Windows versions allow programs
> such as Winzip and AV to violate locks unconditionally.
>
> In the "worst case", something happened on the host machine or the network
> that corrupted data and made it impossible to use the database any more,
> e.g. damaged sectors on disk or network interference that corrupted a page
> write. So, before taking the problem to firebird-devel, Ahmad should shut
> down and restart the server and check whether the application is working.
>
> For any problem report, whether here or in firebird-devel or firebird-test,
> you are wasting your time and ours if you don't provide proper information
> about your environment:
> -- Firebird version (exact)
> -- whether it is SS or Classic
> -- OS platform it is running on
> -- how many concurrent users were online when the event occurred
> -- any excerpts from firebird.log that were written just prior to the
> problem event (do not post the entire log!!)
> -- a copy of the output from gstat -h has the potential to be useful

My problem was really weird, as I was doing some inserts and rollbacks
when that happened. I provided all the information you mentioned above
except the gstat -h.

Before I even posted that, I tried to find any information about that
in your book, but was unable to. I then searched on google and found
something describing IB6, but none of the descriptions given was what
I was doing or what happened in my case. I then posted a message to
firebird-devel and provided as much information as I could.

In my case, I did not have to restart the server. All I did was
restart isql, and it was able to connect to the database without any
problems. After reading the article about IB6, I thought that my
database would end up being corrupted, but it didn't.

Your explanation was clearer, and now I have an idea of what may cause
this to happen.

I really don't want to be wasting people's time, so I was wondering if
there is any troubleshooter's guide that explains the most common
issues we may find, and what the causes are.

I am sorry if I have given the wrong suggestion to Ahmad. It was never
my intention to waste anyone's time.

Thanks.

Fidel.