Re: How to explain the crash? - Informix IDS 7.30 UC8

Seen something similar in Gupta front ended procedure calling. The problem was due to recursion in the SPLs, we could into a situation where the last in a line of SPL calls could ended up calling the original, and bang went the stack and the instance crashed. A review of the logic sort it along with a little bit of recursion depth management. Putting trace on only made it happen sooner Paul Watson WF Software Ltd Tel: +44 1436 674729 Fax: +44 1436 678729 www.wfsoftware.com # If you broke it, hide the evidence >>> "Dong Xiao" <dong_xiao@hotmail.com> 08/04/99 05:25PM >>> Our IDS 7.30 UC8 running on Solaris 2.6 crashed on production under heavy activities(about 2500 userthreads). Here's what the online.log and AF file says: 14:33:58 Who: Session(67858, txw10902@dfsun40, 15214, 0) Thread(81152, sqlexec, 0, 15) File: mtex.c Line: 314 14:33:58 Results: Exception Caught. Type: MT_EX_OS, Context: mem 14:33:58 Action: Please notify Informix Technical Support. 14:34:24 Logical Log 309901 Complete. 14:34:28 Logical Log 309901 - Backup Started 14:34:35 See Also: /production/crash/af.bcb8f246, shmem.bcb8f246.0 14:34:51 See Also: /production/crash/af.bb98f250, shmem.bb98f250.0 14:34:52 See Also: /production/crash/af.c347f23c, shmem.c347f23c.0 14:35:28 See Also: /production/crash/af.bd08f248, shmem.bd08f248.0 14:36:26 See Also: /production/crash/af.3d00f2a5, shmem.3d00f2a5.0 14:37:13 See Also: /production/crash/af.c041f28d, shmem.c041f28d.0 14:37:56 AsserT Failed: No Exception Handler 14:37:56 Informix Dynamic Server Version 7.30.UC8 14:37:56 Who: Session(98620, txw31010@dfsun40, 20818, 0) Thread(118569, sqlexec, 0, 13) File: mtex.c Line: 314 14:37:56 Results: Exception Caught. Type: MT_EX_OS, Context: mem 14:37:56 Action: Please notify Informix Technical Support. 14:41:32 See Also: /production/crash/af.cf29f392, shmem.cf29f392.0 I checked Informix's product defect database and found defect 111839 has very similar symptom. Anyone know if we've a fix for this? This session was running a 'EXECUTE PROCEDURE' from the frontend VB application. And the trace/debug was turned on for this procedure. My question is if turning on trace for procedure has anything to do with the engine crash or has a performance hit? Here I also pasted the stack for the thread: ===========------------- - - - - - - /opt/informix/bin/onstat -g stk 81152 light: Informix Dynamic Server Version 7.30.UC8 -- On-Line -- Up 1 days 22:19:52 -- 1328720 K bytes Stack for thread: 81152 sqlexecbase: 0x3245e630 len: 41472 pc: 0x004178ac tos: 0x32467568 state: running vp: 15 0x00436afc (oninit)afhandler(0x3d00f2a5, 0x6159d0, 0x1, 0x0, 0x1, 0x5dd0ac) 0x00436564 (oninit)afcrash_interface(0x6159d0, 0x32467d48, 0x2da657a0, 0x6159e8, 0x13a, 0 x0) 0x00439b30 (oninit)mt_ex_throw_sig(0x1, 0x5ec8c0, 0x5e6d18, 0x4, 0x1fb6ec04, 0x0) 0xef5388ec (***nosymtab***)0xef5388ec(0xb, 0x0, 0x32467f08, 0x37b82018, 0xb, 0x0) 0x001dde9c (oninit)extend_trace(0x1e189840, 0xb, 0x37b82018, 0x1e4cc788, 0x20000, 0x1) 0x001db558 (oninit)elist_trace(0x1e1898a8, 0x1ca28f90, 0xfffffffc, 0xa0000, 0x0, 0x1) 0x001d96ec (oninit)trace_expr(0x1e1898c8, 0x17, 0x324683d0, 0x1e1899a8, 0x0, 0x57) 0x001d1fd0 (oninit)ip_evalexpr(0x1e1898c8, 0x0, 0x1e4cc438, 0x0, 0x1e4cc430, 0x0) 0x001d13f0 (oninit)runproc (0x0, 0x0, 0x109c, 0x21e9573c, 0x2be50664, 0x21bbc118) 0x001d6b9c (oninit)ip_curnext(0xffffffff, 0x4f, 0x2b97ee18, 0x32468568, 0x0, 0x32468564) 0x001d6a1c (oninit)ip_fetch(0x2b97e030, 0x38, 0x2928f6a0, 0x2928f71c, 0x2928f8e4, 0x25460 8e0) 0x000cf058 (oninit)getrow (0x2b97e030, 0x0, 0x10000000, 0x38, 0x2b97eb08, 0x32468766) 0x000cef1c (oninit)fetchrow(0x2b97e030, 0x258ad690, 0x26334118, 0x2, 0x0, 0x388) 0x001a28e4 (oninit)exfetch (0x2b97e030, 0x2, 0x0, 0x37, 0x39, 0x26335c54) 0x001775b8 (oninit)sq_nfetch(0x1000, 0x0, 0x0, 0x2b97e030, 0x1000, 0x0) 0x00188dd4 (oninit)sqmain (0x646d20, 0x9, 0x64f914, 0x655800, 0x63dce0, 0x0) 0x004199d4 (oninit)startup (0x646d84, 0x0, 0x1c99e908, 0x1c99e908, 0x655800, 0x646c00) 0x00413750 (oninit)mt_poll_yield(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) 0x00000000 (***nosymtab***)0x0 Thank you so much to share! Dong _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************