Re: Assert failed - memory block header corruption IDS 9.4UC2 Solaris 9
Posted in 2004
Topics: Error Codes & Troubleshooting, Platform-Specific Issues, Versions, Editions & End-of-Life
Gary Quiring wrote:
> 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?
No. 9.40.UC5 was released at the end of September.
> 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
So, have you contacted IBM Informix Technical Support?
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
On Fri, 15 Oct 2004 04:12:39 GMT, Jonathan Leffler
<jleffler@earthlink.net> wrote:
>Gary Quiring wrote:
>
>> 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?
>
>No. 9.40.UC5 was released at the end of September.
>
>> 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>
>So, have you contacted IBM Informix Technical Support?
I don't have a contract with IBM. We get support through our VAR
which is basically zippo. It only comes in handy when the DB has a
longtx and IBM comes in and snips the log.
I did find one goof on my part. My physical lg was still on the
rootdb. I setup a chunk for it but forgot to change the onconfig
file. Hopefully that is what caused it to crash.
Gary
"Gary Quiring" <gquiring@msn.com> wrote in message news:psi0n0tcfd60upqtepqs7jutca4jtf8k7k@4ax.com... > On Fri, 15 Oct 2004 04:12:39 GMT, Jonathan Leffler > <jleffler@earthlink.net> wrote: > > >Gary Quiring wrote: > >So, have you contacted IBM Informix Technical Support? > I don't have a contract with IBM. We get support through our VAR > which is basically zippo. It only comes in handy when the DB has a > longtx and IBM comes in and snips the log. This doesn't quite ring true. Informix support via a ISV may well be inferior to that obtained directly from IBM, because of restircted cover hours and the competence of the ISV. But ultimately the ISV's support is backed up by IBM and so you should be able to get this problem resolved. > I did find one goof on my part. My physical lg was still on the > rootdb. I setup a chunk for it but forgot to change the onconfig > file. Hopefully that is what caused it to crash. It won't be.
"Neil Truby" <neil.truby@ardenta.com> wrote in message news:<2tc3sjF1t1mp2U1@uni-berlin.de>... > "Gary Quiring" <gquiring@msn.com> wrote in message > news:psi0n0tcfd60upqtepqs7jutca4jtf8k7k@4ax.com... > > On Fri, 15 Oct 2004 04:12:39 GMT, Jonathan Leffler > > <jleffler@earthlink.net> wrote: > > > > >Gary Quiring wrote: > > >So, have you contacted IBM Informix Technical Support? > > I don't have a contract with IBM. We get support through our VAR > > which is basically zippo. It only comes in handy when the DB has a > > longtx and IBM comes in and snips the log. > > This doesn't quite ring true. Informix support via a ISV may well be > inferior to that obtained directly from IBM, because of restircted cover > hours and the competence of the ISV. But ultimately the ISV's support is > backed up by IBM and so you should be able to get this problem resolved. Provided the ISV reports the problem to IBM. > > > I did find one goof on my part. My physical lg was still on the > > rootdb. I setup a chunk for it but forgot to change the onconfig > > file. Hopefully that is what caused it to crash. > > It won't be.