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.

Hi - if you could all stop laughing for a moment over our outdated
equipment and software (wish I could laugh too), I have a basic
question:

Is a "Segmentation Violation error" usually a system memory problem or
a database problem?

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.
>
> 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***