Hello, I have two instances of Maxdb 7.6.0.32 that have crashed several times due to Shared SQL. To avoid future crashes, we set the setting SHARED_SQL to NO. Can we run maxdb without SharedSql for a long time without other effect than a loss of performance?
The crash occurs when adding a plan to SharedSQL_Plan::mPlanTree. The p pointer in BalanceLeft is null. Can there be concurrent accesses to the tree by several threads ? Below are the information taken from knldiag and KnlMini.dmp 2006-11-07 12:30:47 0xEA8 ERR 18793 EXCEPT EXCEPTION:'Access violation' (0xc0000005), The program code at IP:0x984059 attempted to read to/from address:0x14 2006-11-07 12:30:47 0x668 ERR 19999 BTRACE Eax=0x00000000 Ebx=0x3070b890 Ecx=0x74fab59c Edx=0x1704deff Esi=0x74fab5a0 Edi=0x74fab5a0 2006-11-07 12:30:47 0x668 ERR 19999 BTRACE Eip=0x00984059 Esp=0x1704dda0 Ebp=0x1704dda4 2006-11-07 12:30:47 0x668 ERR 19999 BTRACE Cs=0x001b Ss=0x0023 Ds=0x0023 Es=0x0023 Fs=0x003b Gs=0x0000 Efl=0x10202 I had to decode the stack by hand because the kernel.pdb symbols are no more included with the distribution (why ?) kernel!Container_AVLTree<Container_AVLNode<KernelMem_Page<int> *,KernelMem_DataCacheAllocator<int> >,KernelMem_Page<int> *,KernelMem_DataCacheAllocator<int> >::BalanceLeft+0x9 kernel!Container_AVLTree<SharedSQL_PlanNode,void *,Catalog_ISharedSQLInterface>::InsertNode+0xcf kernel!SharedSQL_Plan::Insert+0x86 kernel!SharedSQL_PrepareHandle::PutPlan+0x37 kernel!Catalog_SessionCache::StorePlanObject+0x6f kernel!Catalog_SessionCache::StorePlan+0xe8 kernel!a101_StorePlan+0xed kernel!ak92StorePlan+0x4a kernel!ak92analyze_messagetype+0x839 kernel!a92_mode_analyzer+0x97 kernel!ak93one_command+0x585 kernel!a93_user_commands+0x40c kernel!SQLTask+0x7b kernel!Kernel_Main+0x223 kernel!RTETask_TaskMain+0x3c Kind regards, GB -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
