MySQL Bugs: #3196: Database crashing on dropping tables or user schema

Bug #3196	Database crashing on dropping tables or user schema
Submitted:	16 Mar 2004 23:35	Modified:	27 Jan 2005 19:03
Reporter:	Adrian Spinei	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MaxDB	Severity:	S2 (Serious)
Version:	7.5.00.08	OS:	Linux (Fedora Linux)
Assigned to:	Ulf Wendel	CPU Architecture:	Any

Description:
A mildly large app (>600 tables). Schema rebuild fails becore MaxDB crashes on the TABLE DROP statements (apparently, when dropping the last table of the schema). DROP USER xxx CASCADE has the same effect. The error report under SQL Studio is :
---- Error -------------------------------
Auto Commit: On, SQL Mode: Internal, Isolation Level: Committed
General error;800 Implicit SERVERDB restart (connection aborted).
DROP User "ASP"
---- Error -------------------------------
Auto Commit: On, SQL Mode: Internal, Isolation Level: Committed
Communication link failure;-807 Connection down, session released.
SELECT DISTINCT DOMAIN.USERS.OWNER,DOMAIN.USERS.GROUPNAME,DOMAIN.USERS.USERNAME,DOMAIN.USERS.USERMODE FROM DOMAIN.USERS WHERE OWNER = 'TEST'  AND DOMAIN.USERS.OWNER != DOMAIN.USERS.USERNAME AND (DOMAIN.USERS.USERMODE !=  'COLDUSER' AND DOMAIN.USERS.USERMODE !=  'ADMIN') ORDER BY GROUPNAME ASC,USERNAME ASC

under jdbc is simply "code 800 : Crash".

Using fast kernel.
If needed, I can provide the ddl script but not publicly, as an attachment ...

How to repeat:
As dba create owned user with schema rights, then create a large schema as the user (will provide incriminated script upon request). Connect as dba and drop the user - instance will crash.

knldiag

Attachment: knldiag.gz (application/x-gzip, text), 11.50 KiB.

knltrace

Attachment: knltrace.gz (application/x-gzip, text), 6.90 KiB.

rtedump

Attachment: rtedump.gz (application/x-gzip, text), 9.29 KiB.

Added schema script.

Dear Mr. Spinei

Thanks for the clear information. To get to the bottom of the problem,
we need the knltrace in a readable format, thus converted to a .prt 
file. You could try to do this with 'xkernprot -f <tracefile> akbnx'
or perhaps better recreate the problem again with trace running. You 
could fairly comfortably handle the whole trace and conversion from 
dbmgui, if you can access the concerned machine from a Windows box.
If you need more info let us know.

rtedump, just in case ...

Attachment: rtedump.gz (application/x-gzip, text), 9.43 KiB.

added files obtained via 'xkernprot -f <tracefile> akbnx'

Hi,

I could not reproduce the problem on a 7.5.00.19 installation. Could you re-run your test with a recent version? If it does not fail on 7.5.00.19, please upgrade to that version. In general we don't provide patches for versions that are not recent any more.

Regards,
Ulf

Hi Adrian,

finally we found that your bug is known and was solved in build .09. See http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1125964 for details.

Thanks for your help!

Regards,
Ulf