Segmentation Violation error

Following is the error file created today. The database had to be taken down by force (kill oninit processes and clear up shared memory). First of all let me tell you that we are running in the stone age. VERY old version on outdated platform. Our management has no intention of upgrading so please don't suggest that's the cure. Even Informix won't support us anymore. Yes I agree, my manager is crazy. Informix version is 7.24 UC3. Platform is a Pyramid Nile, OS is DC/OSX - never heard of it, right? I'd just like some idea as to whether this could have been caused by someone running something they shouldn't have or if it looks like a system problem. Thanks Contents of /tmp/af.4f0b34ef: 10:08:31 Assert Failed: Internal Error - Segmentation Violation 10:08:31 Who: Session(15495, root@jh8, 17769, 729192248) Thread(85771, sqlexec, 2bcc3518, 1) 10:08:31 Results: OnLine must abort 10:08:31 Action: Reinitialize shared memory 10:08:31 See Also: /tmp/af.4f0b34ef 10:08:31 Stack for thread: 85771 sqlexec base: 0x2bf46018 len: 39936 pc: 0x007e50c0 tos: 0x2bf4eb28 0x007e474c mt_affail 0x00697050 rsam_affail 0x0041c830 hang_thread 0x0041c62c afsig_segv 0x00855af8 ifxOS_mutexLock 0x004287fc sqnameerr 0x00574124 lookuptab 0x2b69fc14 ***unknown*** 10:08:32 Bad stack address, unable to continue stack dump"af.4f0b34ef" 47 lines, 1355 characters 10:08:32 ------------------ End of assertion failure 0 ----------------- 10:08:32 10:08:32 Assert Failed: Segmentation Violation 10:08:32 Who: Session(15495, root@jh8, 17769, 0) Thread(85771, sqlexec, 0, 1) 10:08:32 Results: Fatal Internal Error requires system shutdown 10:08:32 Action: Restart OnLine 10:08:32 See Also: /tmp/af.4f0b34ef 10:08:32 Stack for thread: 85771 sqlexec base: 0x2bf46018 len: 39936 pc: 0x007e50c0 tos: 0x2bf4eb50 0x007e474c mt_affail 0x0041c8f8 hang_thread 0x0041c62c afsig_segv 0x00855af8 ifxOS_mutexLock 0x004287fc sqnameerr 0x00574124 lookuptab 0x2b69fc14 ***unknown***

googlemail2003@yahoo.com wrote: > Following is the error file created today. The database had to be > taken down by force (kill oninit processes and clear up shared memory). > > First of all let me tell you that we are running in the stone age. > VERY old version on outdated platform. Our management has no intention > of upgrading so please don't suggest that's the cure. Even Informix > won't support us anymore. Yes I agree, my manager is crazy. > > Informix version is 7.24 UC3. Platform is a Pyramid Nile, OS is DC/OSX > - never heard of it, right? > > I'd just like some idea as to whether this could have been caused by > someone running something they shouldn't have or if it looks like a > system problem. Heard of it - just not recently. If it happens one off, I wouldn't worry too much (though I might be inclined to wonder why root is connecting to a database). I'd probably do a sanity check with oncheck on the system, for peace of mind. If it recurs, then I'd start worrying. > Contents of /tmp/af.4f0b34ef: > > 10:08:31 Assert Failed: Internal Error - Segmentation Violation > 10:08:31 Who: Session(15495, root@jh8, 17769, 729192248) > Thread(85771, sqlexec, 2bcc3518, 1) > 10:08:31 Results: OnLine must abort > 10:08:31 Action: Reinitialize shared memory > 10:08:31 See Also: /tmp/af.4f0b34ef > 10:08:31 Stack for thread: 85771 sqlexec> > base: 0x2bf46018 > len: 39936 > pc: 0x007e50c0 > tos: 0x2bf4eb28 > > 0x007e474c mt_affail > 0x00697050 rsam_affail > 0x0041c830 hang_thread > 0x0041c62c afsig_segv > 0x00855af8 ifxOS_mutexLock > 0x004287fc sqnameerr > 0x00574124 lookuptab > 0x2b69fc14 ***unknown*** > 10:08:32 Bad stack address, unable to continue stack dump> "af.4f0b34ef" 47 lines, 1355 characters > 10:08:32 > ------------------ End of assertion failure 0 ----------------- > > 10:08:32 > 10:08:32 Assert Failed: Segmentation Violation > 10:08:32 Who: Session(15495, root@jh8, 17769, 0) > Thread(85771, sqlexec, 0, 1) > 10:08:32 Results: Fatal Internal Error requires system shutdown > 10:08:32 Action: Restart OnLine > 10:08:32 See Also: /tmp/af.4f0b34ef > 10:08:32 Stack for thread: 85771 sqlexec> > base: 0x2bf46018 > len: 39936 > pc: 0x007e50c0 > tos: 0x2bf4eb50 > > 0x007e474c mt_affail > 0x0041c8f8 hang_thread > 0x0041c62c afsig_segv > 0x00855af8 ifxOS_mutexLock > 0x004287fc sqnameerr > 0x00574124 lookuptab > 0x2b69fc14 ***unknown*** -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/

Jonathan Leffler wrote: > googlemail2003@yahoo.com wrote: > > Following is the error file created today. The database had to be > > taken down by force (kill oninit processes and clear up shared memory). > > > > First of all let me tell you that we are running in the stone age. > > VERY old version on outdated platform. Our management has no intention > > of upgrading so please don't suggest that's the cure. Even Informix > > won't support us anymore. Yes I agree, my manager is crazy. > > > > Informix version is 7.24 UC3. Platform is a Pyramid Nile, OS is DC/OSX > > - never heard of it, right? > > > > I'd just like some idea as to whether this could have been caused by > > someone running something they shouldn't have or if it looks like a > > system problem. > > Heard of it - just not recently. If it happens one off, I wouldn't > worry too much (though I might be inclined to wonder why root is > connecting to a database). I'd probably do a sanity check with oncheck> on the system, for peace of mind. If it recurs, then I'd start worrying. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/ It did recur and I am worried. Decide to reboot the entire system. It had been up for almost three months and sometimes funny things happen to memory when it's up for long periods of time. Trouble is we have three other Informix instances running on this box and they have not been having any problems. My fingers (and everything else I own) are crossed.