Re: Assert failed - memory block header corruption IDS 9.4UC2 Solaris 9
Gery,
Since the block had "def_repl_cntype"...
Are you using ER? Also, are you converting only one server out of
several to 9.4? If so, then you might be running into a problem with
the 7.3 server mis-identifying itself as a 9.4 server when the network
connection is established.
If this sound familar, check your release notes about the CDRSITESxxxx
environmental vairable.
Gary Quiring <gquiring@msn.com> wrote in message news:<5opsm09mh929f3nfek09osjgn1t0u94m1l@4ax.com>...
> I am moving from IDS 7.3 to IDS9.4UC2. In the first days of testing
> the engine crashed. Is 9.4UC2 the latest for Solaris 9?
>
>
> 12:17:10 Assert Failed: Memory block header corruption detected in
> mt_shm_free> 1
> 12:17:10 IBM Informix Dynamic Server Version 9.40.UC2
> 12:17:10 Who: Session(84, root@emco10, 5305, 19c4ace0)
> Thread(95, sqlexec, 19c1f828, 1)
> File: mtshpool.c Line: 3256
> 12:17:10 Results: Unable to repair pool
> 12:17:10 Action: Please notify IBM Informix Technical Support.
> 12:17:10 stack trace for pid 720 written to /tmp/af.4475505
> 12:17:10 See Also: /tmp/af.4475505, shmem.4475505.0
> 12:17:15 Memory block header corruption detected in mt_shm_free 1
> 12:17:15 Assert Failed: No Exception Handler
> 12:17:15 IBM Informix Dynamic Server Version 9.40.UC2
> 12:17:15 Who: Session(84, root@emco10, 5305, 19c4ace0)
> Thread(95, sqlexec, 19c1f828, 1)
> File: mtex.c Line: 431
> 12:17:15 Results: Exception Caught. Type: MT_EX_OS, Context: mem
> 12:17:15 Action: Please notify IBM Informix Technical Support.
> 12:17:15 stack trace for pid 720 written to /tmp/af.4475505
> 12:17:15 See Also: /tmp/af.4475505
> 12:17:19 mtex.c, line 431, thread 95, proc id 720, No Exception
> Handler.
> 12:17:20 The Master Daemon Died
> 12:17:20 PANIC: Attempting to bring system down>
>
> af:
> 12:17:10 Found during mt_shm_free 1
> 12:17:10 Pool 'dictpool' (0x1a07d020)
> 12:17:10 Bad block header 0x1ad14000
> blk-64
> 1ad13fc0: 80000000 0000000f 6465665f 7265706c ........ def_repl
> 1ad13fd0: 5f636e74 79706500 01000004 00400000 _cntype. .....@..
> 1ad13fe0: 80000000 80000000 00000010 6465665f ........ ....def_> 1ad13ff0: 6275696c 645f636e 74797065 01000004 build_cn type....
> blk+64
> 1ad14000: 00400000 80000000 80000000 0000000f .@...... ........
> 1ad14010: 6465665f 6e657374 5f636e74 79706500 def_nest _cntype.
> 1ad14020: 01000004 00400000 80000000 80000000 .....@.. ........
> 1ad14030: 00000010 6465665f 6d657267 655f636e ....def_ merge_cn
> 12:17:10 Multiple block errors found
> 12:17:10
> 12:17:10 Assert Failed: Memory block header corruption detected in
> mt_shm_free> 1
> 12:17:10 Who: Session(84, root@emco10, 5305, 19c4ace0)
> Thread(95, sqlexec, 19c1f828, 1)
> File: mtshpool.c Line: 3256
> 12:17:10 Results: Unable to repair pool
> 12:17:10 Action: Please notify IBM Informix Technical Support.
> 12:17:10 Stack for thread: 95 sqlexec>
> base: 0x1acfe000
> len: 36864
> pc: 0x0071190c
> tos: 0x1ad04d98
> state: running
> vp: 1
>
> 0x00710cf0 (oninit)afhandler(0xb74800, 0x9eb400, 0x19a09678, 0x1,
> 0x401, 0x401)
> 0x00710464 (oninit)affail_interface(0x1ad05528, 0xae6e74, 0x19a09678,
> 0x1, 0xae6
> e8c, 0xcb8)
> 0x007071e8 (oninit)recover_pool_bad_block(0x9ea000, 0x1a07d02c,
> 0xae6e74, 0xffff
> ffff, 0x1a07d020, 0x1ad14000)
> 0x00704780 (oninit)mt_shm_free(0x1a07d02c, 0x1a07d02c, 0xae6824, 0x0,
> 0x1ad14018
> , 0x0)
On 16 Oct 2004 08:52:57 -0700, mpruet@comcast.net (mpruet) wrote: >Gary, > >Since the block had "def_repl_cntype"... > >Are you using ER? Also, are you converting only one server out of >several to 9.4? If so, then you might be running into a problem with >the 7.3 server mis-identifying itself as a 9.4 server when the network >connection is established. > >If this sound familar, check your release notes about the CDRSITESxxxx >environmental vairable. I don't have any replication. I did a grep on CDRSITES in the release directory but got no hits. What does this do? (I am not very Informix savy). Thanks Gary