Hi Urs,
thx for the files. I am still analyzing and it indeed looks like an error we had those times. And in your case the index is corrupt in a way that the subsequent drop of that index (that's exactly what the kernel tries during redo of the log area when you restart it after the original crash) crashes the kernel again.
The error is actually not too simple (I think):
During a balancing operation a page might be locked for WRITE access and be written but not immediately released but cached for subsequent operations with that page. If this subsequent action does not write the page again (for instance because the page is full) it is released as if it was locked for READ access. This way the change on that page could get lost if not another subsequent write operation from another transaction would have changed the page immediately again or at least before the next savepoint. Afterwards there are missing separators on index tree level 1 (separators address the pages below its current level) but the leaf pages of the index addressed by this pages are ok. Now if there is any operation on the index in that region of the corrupt page the index is set to bad. And during dropping the index the kernel finds the chain of separators broken and stops it all.
Ok - the easiest way to overcome all this (and you will face this error again, I wrote it already) is to get the newest available version. Would you mind to find out what exactly stops your development from using the newest version? Usually, the software gets better with newer versions.
And unfortunately there is no option to set an index bad in state ADMIN of the database. To do so SQL access is necessary which is not available in ADMIN state. To be honest - there is a really complicated way to manipulate the internal structures of the database with the right tools but I would not recommend to do it. And in fact it would not help. Even if the index is set bad and you try to drop it, the kernel will crash in your case anyway.
Best regards,
Steffen