Hi, in the meantime it was possible for our developers to crash the database a second time. It's not possible for us to isolate the error. This error blocks the migration from 7.4 to 7.6 for quite a long time and I'd like to know the reason for the crash to eventually make regression tests with newer versions (if the error is fixed there) or to advice our developers to change something in their coding.
The applications which use this database are servlets running in a JBoss-environment. Our Test-JBoss works fine with our test-database (same version, OS and architecture). But if we change the database to a copy of our productive database it crashes very soon. Now I've got a vtrace but don't want to make it publically available because it may contain productive/sensitive data (I had a look at the vtrace but I can't estimate what is contained in it). I would appreciate it if a developer of MaxDB could have a look at this vtrace and other information we've gathered. Regards Chris > -----Original Message----- > From: JUNG, Christian > Sent: Friday, June 01, 2007 5:54 PM > To: MaxDB Mailinglist (E-Mail) > Subject: MaxDB Kernel Crash 7.6.0.36/7.6.1.15 > > > Hi, > > last monday we've tried to update a database which is mainly > used by our > Java-applications from SAP DB version 7.4 (ASCII) to MaxDB > Version 7.6.0.36 > (UNICODE) and then 7.6.1.15. We use the same > binaries/installation procedure > as for our SAP systems. Despite the fact this database is not > used by any of > our SAP systems the bug could threat them too. > > Here are the message from knldiag and knldiag.err: > > knldiag: > ---8<--- > [...] > 2007-05-28 13:13:15 30386 12929 TASKING Task T142 started > 2007-05-28 13:13:15 30386 11007 COMMUNIC wait for connection T142 > 2007-05-28 13:13:15 30386 11561 COMMUNIC Connected T142 > japs02.saarstahl.de 0 > 2007-05-28 13:13:15 30386 11560 COMMUNIC Releasing T142 > 2007-05-28 13:13:15 30386 12827 COMMUNIC wait for connection T142 > 2007-05-28 13:13:15 30370 11561 COMMUNIC Connecting T177 > japs02.saarstahl.de 0 > 2007-05-28 13:13:15 30386 12929 TASKING Task T177 started > 2007-05-28 13:13:15 30386 11007 COMMUNIC wait for connection T177 > 2007-05-28 13:13:15 30386 11561 COMMUNIC Connected T177 > japs02.saarstahl.de 0 > 2007-05-28 13:13:15 30386 11560 COMMUNIC Releasing T177 > 2007-05-28 13:13:15 30386 12827 COMMUNIC wait for connection T177 > +++++++++++++++++++++++++++++++++++++++ Kernel Exit > ++++++++++++++++++++++++++++ > 2007-05-28 13:13:51 0 11987 dump_rte rtedump written to file > 'rtedump' > 2007-05-28 13:13:51 0 ERR 12005 DBCRASH Kernel exited > with core and > exit status 0x8b > 2007-05-28 13:13:51 0 ERR 12012 DBCRASH No stack > backtrace since signal > handler was suppressed by SUPPRESS_CORE=NO > 2007-05-28 13:13:51 0 ERR 12009 DBCRASH Kernel exited > due to signal > 11(SIGSEGV) > 2007-05-28 13:13:51 0 12808 DBSTATE Flushing knltrace pages > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T113 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T121 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T134 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T147 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T153 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T184 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T213 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T242 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T273 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T278 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T289 > kernel abort > 2007-05-28 13:13:52 0 WNG 11824 COMMUNIC Releasing T295 > kernel abort > 2007-05-28 13:13:52 0 12696 DBSTATE Change DbState > to 'OFFLINE > '(29) > ---8<--- > > knldiag.err: > ---8<--- > [...] > 2007-05-28 13:13:51 0 ERR 12005 DBCRASH Kernel exited > with core and > exit status 0x8b > 2007-05-28 13:13:51 0 ERR 12012 DBCRASH No stack > backtrace since signal > handler was suppressed by SUPPRESS_CORE=NO > 2007-05-28 13:13:51 0 ERR 12009 DBCRASH Kernel exited > due to signal > 11(SIGSEGV) > 2007-05-28 13:13:52 ___ Stopping GMT > 2007-05-28 > 11:13:52 7.6.01 Build 015-121-147-649 > ---8<--- > > A stack backtrace with gdb showed this: > > ---8<--- > (gdb) bt > #0 0x0000000000823675 in a93swap_from_application () > #1 0x0000000000823cba in ak93vreceive () > #2 0x0000000000823f29 in a93_user_commands () > #3 0x0000000000d8ae04 in SQLTask () > #4 0x0000000000d8afe3 in Kernel_Main () > #5 0x0000000000e13a48 in RTETask_TaskMain () > #6 0x0000000000ec119c in en88_CallKernelTaskMain () > #7 0x00002b0b5740fe70 in __correctly_grouped_prefixwc () from > /lib64/libc.so.6 > #8 0x0000000000000000 in ?? () > ---8<--- > > ---8<--- > (gdb) info registers > rax 0x4c535f50 1280532304 > rbx 0x142bfc0 21151680 > rcx 0x2 2 > rdx 0x4c535f5e 1280532318 > rsi 0x3 3 > rdi 0x4c535f50 1280532304 > rbp 0x2aacb201ce5f 0x2aacb201ce5f > rsp 0x2aacb201cd60 0x2aacb201cd60 > r8 0x2aacb201cd54 46921209204052 > r9 0x2aacb63d4fdc 46921280212956 > r10 0x2aaaaac2bc08 46912497695752 > r11 0x212 530 > r12 0x2aad0290af30 46922560745264 > r13 0x2aacb201d320 46921209205536 > r14 0x2aacb201cede 46921209204446 > r15 0x2aacb63d4f88 46921280212872 > rip 0x823675 0x823675 <a93swap_from_application+453> > eflags 0x10203 [ CF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > ---8<--- > > A quick look in the source shows, that the function which > crashed here is a > very central one. > > We first migrated to 7.6.0.36 (normal installation, import of data via > loadercli). The database was running for approximatley 5 > hours then the > kernel crashed the first time (same backtrace btw.). > Afterwards we updated > to version 7.6.1.15 but the databases crashed again multiple times. > > The database runs on a 8 way Intel Core2 machine with 32GB > RAM and SuSE > SLES10 x86_64 (Linux kernel 2.6.16). > > Now I try to provoke the error; could you give me a hint? > Maybe the request > is too big for an internal buffer or the like? > > Thanks a lot for your help! > > > bye > Chris > > phone: +49 6898/10-4987 > fax: +49 6898/10-54987 > http://www.saarstahl.de > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
