Subject | Re: fbserver.exe terminated abnormally (4294967295) |
---|---|
Author | Svein Erling Tysvær |
Post date | 2005-10-14T17:31:55Z |
--- In firebird-support@yahoogroups.com, "Ann W. Harrison" wrote:
the time of crashing was originally created on the other server and
then migrated (through some hassles, due to the external file and
having sat ExternalFileAccess=NONE (or similar). I think it was done
through backup/restore, but Aage's memory is normally better than
mine.
Moreover, the crashing server runs Firebird 1.5.2 and is in use all
the time, the non-crashing server runs Firebird 1.5.1 and is
occasionally used for testing purposes, but mostly runs other
software. The simple test I used, only created one external table with
one field (in another database that already had a table that I left
untouched), when the crash occured I modified an empty table with
possibly 100 fields that had contained possibly around 1000000 records
before being emptied. The database itself contains about 12000000 in a
couple of tables (views are also defined, though I don't think I've
tried using views over the external table ;o) if I remember correctly.
Now, I don't know whether I actually crashed the server, I actually
never noticed that the server went down before Aage told me. I just
know that I three minutes after the crash sent Aage a mail telling
that I had removed the external table and just concluded that I'd
probably done that at the time of crashing. Of course others may have
caused the crash as well, I am just more suspicious about my behaviour
since I know it must have happened within three minutes before or
after the crash and that I did something I'd never done before,
whereas our coders have been using Aages program for several years
without crashing anything. Also, I noticed that Firebird Workbench
didn't allow me to remove the external table declaration - and thought
that maybe Martijn had been made aware of some potential error and
tried to prevent his users from making a mistake, something I
circumvented through using IB_SQL.
>Well, the database where I removed the external file approximately at
> Svein Erling Tysvær wrote:
> >
> > I did a RECREATE TABLE A (<fieldname> ... to get rid of an
> > external file that stored this table before. The table was
> > completely empty, and I was most likely the only person attached
> > to that database at that time (though I was accessing it from both
> > IB_SQL and Database WorkBench). I am normally the only person
> > using that database and no DML was done, just DDL.
> >
> > Am I correct in guessing that this is a probable cause?
>
> What you did should not have crashed the server. unh, duh! SQL
> features shouldn't cause the database to crash (reminds me vaguely
> of a story variously told about several Computer Science schools,
> which, in the early days, ran lots of home-brewed system software.
> Students made a game of figuring out how to crash the system and got
> imaginative enough to be really annoying to the people who were
> trying to get work done. Adding a new user-level command CRASH took
> all the sport out of the game, restoring stability to the lab.)
>
> Recreate table should not crash the server... And you should not
> crash the production server just to see if the problem can be
> reproduced there. Any clues as to what's different between the
> database that caused the failure and the one that didn't?
the time of crashing was originally created on the other server and
then migrated (through some hassles, due to the external file and
having sat ExternalFileAccess=NONE (or similar). I think it was done
through backup/restore, but Aage's memory is normally better than
mine.
Moreover, the crashing server runs Firebird 1.5.2 and is in use all
the time, the non-crashing server runs Firebird 1.5.1 and is
occasionally used for testing purposes, but mostly runs other
software. The simple test I used, only created one external table with
one field (in another database that already had a table that I left
untouched), when the crash occured I modified an empty table with
possibly 100 fields that had contained possibly around 1000000 records
before being emptied. The database itself contains about 12000000 in a
couple of tables (views are also defined, though I don't think I've
tried using views over the external table ;o) if I remember correctly.
Now, I don't know whether I actually crashed the server, I actually
never noticed that the server went down before Aage told me. I just
know that I three minutes after the crash sent Aage a mail telling
that I had removed the external table and just concluded that I'd
probably done that at the time of crashing. Of course others may have
caused the crash as well, I am just more suspicious about my behaviour
since I know it must have happened within three minutes before or
after the crash and that I did something I'd never done before,
whereas our coders have been using Aages program for several years
without crashing anything. Also, I noticed that Firebird Workbench
didn't allow me to remove the external table declaration - and thought
that maybe Martijn had been made aware of some potential error and
tried to prevent his users from making a mistake, something I
circumvented through using IB_SQL.