IDS 7.31.UD3
Solaris 8

SQL:
select item
from table, sysmaster:syssessions
where some joins

This query is run upto 5-10 times per second at the engine level and
within the app is to ensure only one version of a particular program is
running out on the 8 app servers

The DB stays up for 5-12 days and then crashes. It restarts every time.
The af always shows the same SQL. Personally I think it is an
application design issue but the app vendor disagrees.

Any one seen anything similar, a bug number would be useful

Paul Watson
Tel: +44 1414161772
Mob: +44 7818003457

GO FURTHER with DB2
GET THERE FASTER with Informix.
Attend the IDUG 2006 North America Conference.
Tampa, Florida, USA. 7-11 May 2006.
Visit http://www.iiug.org/conf for more information.

Can you post the stack from the AF?

Paul Watson wrote:
> IDS 7.31.UD3
> Solaris 8
>
> SQL:
> select item
> from table, sysmaster:syssessions
> where some joins
>
> This query is run upto 5-10 times per second at the engine level and
> within the app is to ensure only one version of a particular program is
> running out on the 8 app servers
>
> The DB stays up for 5-12 days and then crashes. It restarts every time.
> The af always shows the same SQL. Personally I think it is an
> application design issue but the app vendor disagrees.
>
> Any one seen anything similar, a bug number would be useful
>
> Paul Watson
> Tel: +44 1414161772
> Mob: +44 7818003457
>
> GO FURTHER with DB2
> GET THERE FASTER with Informix.
> Attend the IDUG 2006 North America Conference.
> Tampa, Florida, USA. 7-11 May 2006.
> Visit http://www.iiug.org/conf for more information.
>
>
>

> Can you post the stack from the AF?
>
> Paul Watson wrote:
> > IDS 7.31.UD3
> > Solaris 8
> >
> > SQL:
> > select item
> > from table, sysmaster:syssessions
> > where some joins
> >
> > This query is run upto 5-10 times per second at the engine level and
> > within the app is to ensure only one version of a
> particular program is
> > running out on the 8 app servers
> >
> > The DB stays up for 5-12 days and then crashes. It
> restarts every time.
> > The af always shows the same SQL. Personally I think it is an
> > application design issue but the app vendor disagrees.
> >
> > Any one seen anything similar, a bug number would be useful
> >
Informix Dynamic Server Version 7.31.UD3 -- On-Line (Prim) -- Up 3
days 00:48:38 -- 3952832 Kbytes

Stack for thread: 552447 sqlexec
base: 0xa598e000
len: 40960
pc: 0x00442c34
tos: 0xa5996ab8
state: running
vp: 4

0x00462158 (oninit)afhandler(0x3, 0x728390, 0x728198, 0x1, 0x71e71bc6,
0x1)
0x00461bf0 (oninit)afcrash_interface(0x6e66a4, 0xa59972a0, 0x4150a9c8,
0x6e66bc, 0x1c6, 0x0)
0x0046543c (oninit)mt_ex_throw_sig(0x6a8400, 0x602e07d4, 0x0, 0x0, 0x0,
0x0)
0x000b2450 (oninit)afsig_segv(0x0, 0x38fc9778, 0x0, 0x38fc96d8,
0x200000, 0x728000)
0x003410e4 (oninit)prrstcb (0x1e37c, 0x3805a018, 0x71982c, 0xa00a800,
0x38078394, 0x2)
0x003391c8 (oninit)pstread (0x71982c, 0x1, 0x0, 0x2, 0x8ff0dcb4,
0xa5997ce8)
0x0028c434 (oninit)pst_rsread(0x8ff0dcb4, 0x71982c, 0x2, 0x8ff0dc58,
0xd8b4d5d0, 0xac)
0x0028d4e8 (oninit)rsread (0x719570, 0xd8b4d418, 0x71982c, 0x2, 0x0,
0x8ff0dc58)
0x004d0480 (oninit)fmread (0x14, 0xd8b4d374, 0x1, 0x0, 0x51d7bfd8,
0x51d7bf70)
0x000eaa0c (oninit)sqisread(0x719518, 0xd8b4d374, 0x102, 0x8d, 0xd8,
0x2)
0x000f370c (oninit)readseq (0x10000, 0x719518, 0x0, 0x14, 0x0, 0x0)
0x000f3050 (oninit)gettupl (0x1000, 0x8000, 0x3fd5dc20, 0x4000000,
0x10000, 0x4000020)
0x000f0ee4 (oninit)scan_next(0xd8b4d270, 0x10, 0x719518, 0xd8b4d270,
0xd98ee01c, 0xa9fc40e8)
0x0010981c (oninit)hjoin_open(0x719518, 0x0, 0x2c, 0xd8b4c258,
0xd98f9082, 0xa5997ce8)
0x000f87d8 (oninit)prepselect(0x72c108, 0x1226, 0x719518, 0x3fc63c20,
0x3fca2020, 0x3fc63c30)
0x0019c5c0 (oninit)open_cursor(0x1000, 0x72c108, 0x3fc63c30, 0x3fc63c30,
0xa5997eac, 0x0)
0x0019bfc8 (oninit)sq_open (0x72c000, 0x2, 0x72c108, 0x2000, 0x20000,
0x0)
0x001af998 (oninit)sqmain (0x6, 0x72c000, 0x669800, 0x719518, 0x72214c,
0x38654018)
0x00444bb0 (oninit)startup (0x728390, 0x7, 0x0, 0x38010958, 0x3864ff10,
0x38010918)
0x0043ea2c (oninit)mt_poll_yield(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
0x00000000 (***nosymtab***)0x0

Paul Watson
Tel: +44 1414161772
Mob: +44 7818003457

GO FURTHER with DB2
GET THERE FASTER with Informix.
Attend the IDUG 2006 North America Conference.
Tampa, Florida, USA. 7-11 May 2006.
Visit http://www.iiug.org/conf for more information.

There is a bug which describes your problem...
159509 SERVER CAN CRASH WITH SEGV IN PRRSTCB() WHEN SYSMASTER QUERY
INVOLVES SYSRSTCB TABLE

Note sysmaster:syssessions is a view which references sysrstcb.

This bug is fixed in 7.31.UD7.

Regards
Guy

Paul Watson wrote:
>> Can you post the stack from the AF?
>>
>> Paul Watson wrote:
>>> IDS 7.31.UD3
>>> Solaris 8
>>>
>>> SQL:
>>> select item
>>> from table, sysmaster:syssessions
>>> where some joins
>>>
>>> This query is run upto 5-10 times per second at the engine level and
>>> within the app is to ensure only one version of a
>> particular program is
>>> running out on the 8 app servers
>>>
>>> The DB stays up for 5-12 days and then crashes. It
>> restarts every time.
>>> The af always shows the same SQL. Personally I think it is an
>>> application design issue but the app vendor disagrees.
>>>
>>> Any one seen anything similar, a bug number would be useful
>>>
> Informix Dynamic Server Version 7.31.UD3 -- On-Line (Prim) -- Up 3
> days 00:48:38 -- 3952832 Kbytes
>
> Stack for thread: 552447 sqlexec
> base: 0xa598e000
> len: 40960
> pc: 0x00442c34
> tos: 0xa5996ab8
> state: running
> vp: 4
>
> 0x00462158 (oninit)afhandler(0x3, 0x728390, 0x728198, 0x1, 0x71e71bc6,
> 0x1)
> 0x00461bf0 (oninit)afcrash_interface(0x6e66a4, 0xa59972a0, 0x4150a9c8,
> 0x6e66bc, 0x1c6, 0x0)
> 0x0046543c (oninit)mt_ex_throw_sig(0x6a8400, 0x602e07d4, 0x0, 0x0, 0x0,
> 0x0)
> 0x000b2450 (oninit)afsig_segv(0x0, 0x38fc9778, 0x0, 0x38fc96d8,
> 0x200000, 0x728000)
> 0x003410e4 (oninit)prrstcb (0x1e37c, 0x3805a018, 0x71982c, 0xa00a800,
> 0x38078394, 0x2)
> 0x003391c8 (oninit)pstread (0x71982c, 0x1, 0x0, 0x2, 0x8ff0dcb4,
> 0xa5997ce8)
> 0x0028c434 (oninit)pst_rsread(0x8ff0dcb4, 0x71982c, 0x2, 0x8ff0dc58,
> 0xd8b4d5d0, 0xac)
> 0x0028d4e8 (oninit)rsread (0x719570, 0xd8b4d418, 0x71982c, 0x2, 0x0,
> 0x8ff0dc58)
> 0x004d0480 (oninit)fmread (0x14, 0xd8b4d374, 0x1, 0x0, 0x51d7bfd8,
> 0x51d7bf70)
> 0x000eaa0c (oninit)sqisread(0x719518, 0xd8b4d374, 0x102, 0x8d, 0xd8,
> 0x2)
> 0x000f370c (oninit)readseq (0x10000, 0x719518, 0x0, 0x14, 0x0, 0x0)
> 0x000f3050 (oninit)gettupl (0x1000, 0x8000, 0x3fd5dc20, 0x4000000,
> 0x10000, 0x4000020)
> 0x000f0ee4 (oninit)scan_next(0xd8b4d270, 0x10, 0x719518, 0xd8b4d270,
> 0xd98ee01c, 0xa9fc40e8)
> 0x0010981c (oninit)hjoin_open(0x719518, 0x0, 0x2c, 0xd8b4c258,
> 0xd98f9082, 0xa5997ce8)
> 0x000f87d8 (oninit)prepselect(0x72c108, 0x1226, 0x719518, 0x3fc63c20,
> 0x3fca2020, 0x3fc63c30)
> 0x0019c5c0 (oninit)open_cursor(0x1000, 0x72c108, 0x3fc63c30, 0x3fc63c30,
> 0xa5997eac, 0x0)
> 0x0019bfc8 (oninit)sq_open (0x72c000, 0x2, 0x72c108, 0x2000, 0x20000,
> 0x0)
> 0x001af998 (oninit)sqmain (0x6, 0x72c000, 0x669800, 0x719518, 0x72214c,
> 0x38654018)
> 0x00444bb0 (oninit)startup (0x728390, 0x7, 0x0, 0x38010958, 0x3864ff10,
> 0x38010918)
> 0x0043ea2c (oninit)mt_poll_yield(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
> 0x00000000 (***nosymtab***)0x0
>
> Paul Watson
> Tel: +44 1414161772
> Mob: +44 7818003457
>
> GO FURTHER with DB2
> GET THERE FASTER with Informix.
> Attend the IDUG 2006 North America Conference.
> Tampa, Florida, USA. 7-11 May 2006.
> Visit http://www.iiug.org/conf for more information.
>

One more thing.. If they still get a problem with 7.31.UD7 or later,
there is a similar less frequent problem:
166587 OCCASSIONAL AF ON BUSY SYSTEM IN PRRSTCB FOR QUERY WHICH USES
SYSRSTCB TABLE
which is fixed 9.40.UC6, 10.00.UC1 but not 7.x. If they need a fix for
that in 7.x they could ask for a patch.

Guy

Guy Bowerman wrote:
> There is a bug which describes your problem...
> 159509 SERVER CAN CRASH WITH SEGV IN PRRSTCB() WHEN SYSMASTER QUERY
> INVOLVES SYSRSTCB TABLE
>
> Note sysmaster:syssessions is a view which references sysrstcb.
>
> This bug is fixed in 7.31.UD7.
>
> Regards
> Guy
>
> Paul Watson wrote:
>>> Can you post the stack from the AF?
>>>
>>> Paul Watson wrote:
>>>> IDS 7.31.UD3
>>>> Solaris 8
>>>>
>>>> SQL:
>>>> select item from table, sysmaster:syssessions where some joins
>>>>
>>>> This query is run upto 5-10 times per second at the engine level and
>>>> within the app is to ensure only one version of a
>>> particular program is
>>>> running out on the 8 app servers
>>>>
>>>> The DB stays up for 5-12 days and then crashes. It
>>> restarts every time.
>>>> The af always shows the same SQL. Personally I think it is an
>>>> application design issue but the app vendor disagrees.
>>>>
>>>> Any one seen anything similar, a bug number would be useful
>>>>
>> Informix Dynamic Server Version 7.31.UD3 -- On-Line (Prim) -- Up 3
>> days 00:48:38 -- 3952832 Kbytes
>>
>> Stack for thread: 552447 sqlexec
>> base: 0xa598e000
>> len: 40960
>> pc: 0x00442c34
>> tos: 0xa5996ab8
>> state: running
>> vp: 4
>>
>> 0x00462158 (oninit)afhandler(0x3, 0x728390, 0x728198, 0x1, 0x71e71bc6,
>> 0x1)
>> 0x00461bf0 (oninit)afcrash_interface(0x6e66a4, 0xa59972a0, 0x4150a9c8,
>> 0x6e66bc, 0x1c6, 0x0)
>> 0x0046543c (oninit)mt_ex_throw_sig(0x6a8400, 0x602e07d4, 0x0, 0x0, 0x0,
>> 0x0)
>> 0x000b2450 (oninit)afsig_segv(0x0, 0x38fc9778, 0x0, 0x38fc96d8,
>> 0x200000, 0x728000)
>> 0x003410e4 (oninit)prrstcb (0x1e37c, 0x3805a018, 0x71982c, 0xa00a800,
>> 0x38078394, 0x2)
>> 0x003391c8 (oninit)pstread (0x71982c, 0x1, 0x0, 0x2, 0x8ff0dcb4,
>> 0xa5997ce8)
>> 0x0028c434 (oninit)pst_rsread(0x8ff0dcb4, 0x71982c, 0x2, 0x8ff0dc58,
>> 0xd8b4d5d0, 0xac)
>> 0x0028d4e8 (oninit)rsread (0x719570, 0xd8b4d418, 0x71982c, 0x2, 0x0,
>> 0x8ff0dc58)
>> 0x004d0480 (oninit)fmread (0x14, 0xd8b4d374, 0x1, 0x0, 0x51d7bfd8,
>> 0x51d7bf70)
>> 0x000eaa0c (oninit)sqisread(0x719518, 0xd8b4d374, 0x102, 0x8d, 0xd8,
>> 0x2)
>> 0x000f370c (oninit)readseq (0x10000, 0x719518, 0x0, 0x14, 0x0, 0x0)
>> 0x000f3050 (oninit)gettupl (0x1000, 0x8000, 0x3fd5dc20, 0x4000000,
>> 0x10000, 0x4000020)
>> 0x000f0ee4 (oninit)scan_next(0xd8b4d270, 0x10, 0x719518, 0xd8b4d270,
>> 0xd98ee01c, 0xa9fc40e8)
>> 0x0010981c (oninit)hjoin_open(0x719518, 0x0, 0x2c, 0xd8b4c258,
>> 0xd98f9082, 0xa5997ce8)
>> 0x000f87d8 (oninit)prepselect(0x72c108, 0x1226, 0x719518, 0x3fc63c20,
>> 0x3fca2020, 0x3fc63c30)
>> 0x0019c5c0 (oninit)open_cursor(0x1000, 0x72c108, 0x3fc63c30, 0x3fc63c30,
>> 0xa5997eac, 0x0)
>> 0x0019bfc8 (oninit)sq_open (0x72c000, 0x2, 0x72c108, 0x2000, 0x20000,
>> 0x0)
>> 0x001af998 (oninit)sqmain (0x6, 0x72c000, 0x669800, 0x719518, 0x72214c,
>> 0x38654018)
>> 0x00444bb0 (oninit)startup (0x728390, 0x7, 0x0, 0x38010958, 0x3864ff10,
>> 0x38010918)
>> 0x0043ea2c (oninit)mt_poll_yield(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
>> 0x00000000 (***nosymtab***)0x0
>>
>> Paul Watson
>> Tel: +44 1414161772 Mob: +44 7818003457
>>
>> GO FURTHER with DB2
>> GET THERE FASTER with Informix.
>> Attend the IDUG 2006 North America Conference.
>> Tampa, Florida, USA. 7-11 May 2006.
>> Visit http://www.iiug.org/conf for more information.
>>