Informix crashes with wrong datatype in stored procedure
Posted in 2003
Topics: Stored Procedures & SPL, Error Codes & Troubleshooting, Server Administration, Data Types & Schema Design, Versions, Editions & End-of-Life, Jobs, Consulting & Announcements
IDS 9.21.UC4XE
Solaris 2.6.
We experiences an annoying informix crash today, which was
eventually traced to a bug in informix regarding mismatched
data type.
Here is a simple test case to crash informix. I am taking
care to reproduce the logic of our stored procedure as much
as possible, specially in parameters and return datatype.
create function call_1(p_in integer) returning decimal(8,4)
define w_ret decimal(8,4); foreach execute function call_2(p_in) into w_ret
return w_ret with resume ;
end foreach ;
end function ;
create function call_2(p_in smallint) returning decimal(8,4)
define w_ret decimal(8,4); foreach select fld1 into w_ret
from sometable
return w_ret with resume ;
end foreach ;
end function ;
Note that there is a coding bug in function call_2. It declares
the input parameter as smallint instead of integer.
You may have to create a table sometable with a single column
fld1 of decimal(8,4). Put some values there.
Now to test the bug:-
from dbaccess:-
execute function call_1(3600); -- works fine.
execute function call_1(63600); -- crashes the server
if the signature of the function call_2 is changes to p_in integer,
it runs fine.
head of the af file:-
21:43:20 Informix Dynamic Server 2000 Version 9.21.UC4XE
21:43:21 Assert Failed: No Exception Handler
21:43:21 Who: Session(20, dba@matrix, 3570, 170117356)
Thread(44, sqlexec, a20ddc8, 1)
File: mtex.c Line: 405
21:43:21 Results: Exception Caught. Type: MT_EX_OS, Context: mem
21:43:21 Action: Please notify Informix Technical Support.
21:43:21 Stack for thread: 44 sqlexec
base: 0x0a9de000
len: 36864
pc: 0x006b43d0
tos: 0x0a9e5ca0
state: running
vp: 1
0x006b3794 (oninit)afhandler(0x414e838, 0x1, 0x0, 0xa23c8ec, 0x3, 0xa20ddc8)
0x006b3200 (oninit)afcrash_interface(0x9a7794, 0xa9e63f8, 0xa3fefc0, 0x9a77ac, 0x195, 0x0)
0x006b76e4 (oninit)mt_ex_throw_sig(0x1, 0x9a4ae0, 0x4, 0xffffffff, 0x1, 0xff)
0x006876b0 (oninit)afsig_handler(0xa438c80, 0xa436020, 0x9a627c, 0xa23dc0, 0xa443114, 0x12d2)
0x0016940c (oninit)altcontext(0xffffffff, 0xa0f164, 0xa443108, 0xa465030, 0x0, 0xa43a2b0)
0x0016c16c (oninit)ip_clscur(0xffffffff, 0xa0f000, 0x0, 0x0, 0xa465030, 0x20000)
0x0016bffc (oninit)ip_close(0xa45d488, 0xa0f400, 0xa036800, 0x8f8000, 0xa3f1ed4, 0xa3f1f68)
0x003e0e34 (oninit)closecb (0xa45d488, 0x20, 0xa0f164, 0x38, 0x0, 0x0)
0x003e07e0 (oninit)close_cb_subtree_r(0xa443018, 0x20, 0xa45d488, 0xa45d488, 0x20, 0xa443018)
0x003e0714 (oninit)close_cb_subtree(0xa443018, 0x20, 0xa45d488, 0xa401170, 0xa4010d8, 0xa23c00)
0x003e0398 (oninit)closesdb(0x8c9748, 0x0, 0x0, 0x1, 0xa45d810, 0x0)
0x00344b10 (oninit)close_cursor(0xffffffff, 0xa23dc0, 0x12ca, 0x1000, 0x12d2, 0xa45d488)
0x00344850 (oninit)sq_close(0x28, 0x134e, 0x1, 0x0, 0xa443018, 0x10)
0x003bc0a4 (oninit)sqmain (0xa18568, 0x8c9400, 0xa23c00, 0x8ee078, 0xfffdffff, 0x20000)
0x00694698 (oninit)startup (0xa1e400, 0xa0f400, 0xa107270, 0x0, 0x0, 0xa107270)
0x006886ac (oninit)idle_processor(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
0x00000000 (*nosymtab*)0x0
two typos:- > We experiences experienced. > if the signature of the function call_2 is changes to p_in integer, is changed to
I've just discovered our 9.20.UC2/Solaris 7 fails to order correctly
within SPL if you select char into a HTML datatype
rkusenet wrote:
>
> IDS 9.21.UC4XE
> Solaris 2.6.
>
> We experiences an annoying informix crash today, which was
> eventually traced to a bug in informix regarding mismatched
> data type.
>
> Here is a simple test case to crash informix. I am taking
> care to reproduce the logic of our stored procedure as much
> as possible, specially in parameters and return datatype.
>
> create function call_1(p_in integer) returning decimal(8,4)
> define w_ret decimal(8,4);> foreach execute function call_2(p_in) into w_ret
> return w_ret with resume ;
> end foreach ;
> end function ;
>
> create function call_2(p_in smallint) returning decimal(8,4)
> define w_ret decimal(8,4);> foreach select fld1 into w_ret
> from sometable
> return w_ret with resume ;
> end foreach ;
> end function ;
>
> Note that there is a coding bug in function call_2. It declares
> the input parameter as smallint instead of integer.
>
> You may have to create a table sometable with a single column
> fld1 of decimal(8,4). Put some values there.
>
> Now to test the bug:-
>
> from dbaccess:-
>
> execute function call_1(3600); -- works fine.>
> execute function call_1(63600); -- crashes the server>
> if the signature of the function call_2 is changes to p_in integer,
> it runs fine.
>
> head of the af file:-
>
> 21:43:20 Informix Dynamic Server 2000 Version 9.21.UC4XE
> 21:43:21 Assert Failed: No Exception Handler
> 21:43:21 Who: Session(20, dba@matrix, 3570, 170117356)
> Thread(44, sqlexec, a20ddc8, 1)
> File: mtex.c Line: 405
> 21:43:21 Results: Exception Caught. Type: MT_EX_OS, Context: mem
> 21:43:21 Action: Please notify Informix Technical Support.
> 21:43:21 Stack for thread: 44 sqlexec>
> base: 0x0a9de000
> len: 36864
> pc: 0x006b43d0
> tos: 0x0a9e5ca0
> state: running
> vp: 1
>
> 0x006b3794 (oninit)afhandler(0x414e838, 0x1, 0x0, 0xa23c8ec, 0x3, 0xa20ddc8)
> 0x006b3200 (oninit)afcrash_interface(0x9a7794, 0xa9e63f8, 0xa3fefc0, 0x9a77ac, 0x195, 0x0)
> 0x006b76e4 (oninit)mt_ex_throw_sig(0x1, 0x9a4ae0, 0x4, 0xffffffff, 0x1, 0xff)
> 0x006876b0 (oninit)afsig_handler(0xa438c80, 0xa436020, 0x9a627c, 0xa23dc0, 0xa443114, 0x12d2)
> 0x0016940c (oninit)altcontext(0xffffffff, 0xa0f164, 0xa443108, 0xa465030, 0x0, 0xa43a2b0)
> 0x0016c16c (oninit)ip_clscur(0xffffffff, 0xa0f000, 0x0, 0x0, 0xa465030, 0x20000)
> 0x0016bffc (oninit)ip_close(0xa45d488, 0xa0f400, 0xa036800, 0x8f8000, 0xa3f1ed4, 0xa3f1f68)
> 0x003e0e34 (oninit)closecb (0xa45d488, 0x20, 0xa0f164, 0x38, 0x0, 0x0)
> 0x003e07e0 (oninit)close_cb_subtree_r(0xa443018, 0x20, 0xa45d488, 0xa45d488, 0x20, 0xa443018)
> 0x003e0714 (oninit)close_cb_subtree(0xa443018, 0x20, 0xa45d488, 0xa401170, 0xa4010d8, 0xa23c00)
> 0x003e0398 (oninit)closesdb(0x8c9748, 0x0, 0x0, 0x1, 0xa45d810, 0x0)
> 0x00344b10 (oninit)close_cursor(0xffffffff, 0xa23dc0, 0x12ca, 0x1000, 0x12d2, 0xa45d488)
> 0x00344850 (oninit)sq_close(0x28, 0x134e, 0x1, 0x0, 0xa443018, 0x10)
> 0x003bc0a4 (oninit)sqmain (0xa18568, 0x8c9400, 0xa23c00, 0x8ee078, 0xfffdffff, 0x20000)
> 0x00694698 (oninit)startup (0xa1e400, 0xa0f400, 0xa107270, 0x0, 0x0, 0xa107270)
> 0x006886ac (oninit)idle_processor(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
> 0x00000000 (*nosymtab*)0x0
--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #
"rkusenet" <rkusenet@sympatico.ca> wrote > IDS 9.21.UC4XE > Solaris 2.6. A friend of mine ran this bug script on 9.30.UC3 and 9.40. 9.30 crashed the server, but 9.40 did not. Ravi