Stored procedure returns -881
A stored procedure on IDS 7.30.UC7 (HP-UX) that builds a string and passes it to SYSTEM() to run a 4GL program intermittently failed with error -881 (TRIM returned a string outside the 1-255 character VARCHAR range); it only worked again after being re-created and run once from dbaccess. Separately, using SET DEBUG FILE TO / TRACE ON crashed the engine with an assertion in mtex.c and a PANIC. One reply suggested trimming trailing spaces so the built string stays under 255 chars; after examining the af stack trace (a segfault in free() while printing a value inside a procedure), David Williams concluded it looked like an engine bug and advised upgrading to 7.31.UC4-1. No confirmation of a fix is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi
We have a problem with stored procedure that is called via onsoctcp
network connection. This procedure is constructing a string that
is passed to the SYSTEM command which executes a *.4ge program with
some parameters. This procedure is acting strange - it is loaded into
the database, and then some tests are performed - everything works great.
The next morning some more testing is done, and the procedure crashes with
exception -881. When it is reloaded via dbaccess , and then executed from it
too - everything starts working again. If we just reload the procedure, it's
still returning -881, we must call it once from dbaccess, not from our client
program to get it to work again.
All that we know is that this -881 happens when the SYSTEM() is called.
The other problem we have is that our online crashes EVERY time whe we try
to use SET DEBUG FILE TO , and TRACE ON commands in stored procedures.
The system we working on is T500 with HP-UX 10.30 and Online 7.30
Maybe someone can help ?
thanks
--
Wojtek Mitus
-----------
wm@biol.uni.wroc.pl
In article <80ut9t$f78$1@panorama.pwr.wroc.pl>, wm@biol.uni.wroc.pl
writes
>Hi
>
>We have a problem with stored procedure that is called via onsoctcp
>network connection. This procedure is constructing a string that
>is passed to the SYSTEM command which executes a *.4ge program with
>some parameters. This procedure is acting strange - it is loaded into
>the database, and then some tests are performed - everything works great.
>The next morning some more testing is done, and the procedure crashes with
>exception -881. When it is reloaded via dbaccess , and then executed from it
>too - everything starts working again. If we just reload the procedure, it's
>still returning -881, we must call it once from dbaccess, not from our client
>program to get it to work again.
>
>All that we know is that this -881 happens when the SYSTEM() is called.
>
What is -881?
>The other problem we have is that our online crashes EVERY time whe we try
>to use SET DEBUG FILE TO , and TRACE ON commands in stored procedures.
>
Do you get an af file? What is in the online.log ?
>The system we working on is T500 with HP-UX 10.30 and Online 7.30
>Maybe someone can help ?
>
>thanks
>
--
David Williams
David Williams <djw@smooth1.demon.co.uk> wrote:
> What is -881?
Hi
this is finderr -881:
The TRIM function returned a string whose length did not span a range
from 1 to 255 characters. The TRIM function returns a VARCHAR string.
A VARCHAR string must have a length that ranges from 1 character to 255
characters. Check that the TRIM function returns strings whose length
is within that range.
>>The other problem we have is that our online crashes EVERY time whe we try
>>to use SET DEBUG FILE TO , and TRACE ON commands in stored procedures.
>>
> Do you get an af file? What is in the online.log ?
Yep. An af file is about 500 kbytes, so i can't include it here. Online.log
looks like that:
17:36:28 Logical Log 4726 - Backup Completed
17:38:14 Checkpoint Completed: duration was 10 seconds.
17:41:21 Assert Failed: No Exception Handler
17:41:21 Informix Dynamic Server Version 7.30.UC7
17:41:21 Who: Session(32709, promak@nt_work_2, 145, 0)
Thread(52251, sqlexec, 0, 3)
File: mtex.c Line: 314
17:41:21 Results: Exception Caught. Type: MT_EX_OS, Context: mem
17:41:21 Action: Please notify Informix Technical Support.
17:41:21 stack trace for pid 1639 written to /opt/informix/af.cc1b8930
17:43:26 Checkpoint Completed: duration was 8 seconds.
17:45:16 ÖXČÖ&9Ź~ÍI, shmem.cc1b8930.0
17:49:06 mtex.c, line 314, thread 52251, proc id 1639, No Exception Handler.
17:49:33 PANIC: Attempting to bring system down
Tue Nov 16 18:00:10 1999
18:00:10 Event alarms enabled. ALARMPROG = '/opt/informix/etc/log_full.sh'
18:00:15 DR: DRAUTO is 0 (Off)
18:00:16 Informix Dynamic Server Version 7.30.UC7 Software Serial Number ACN#J165375
18:00:19 (8) connection rejected - no calls allowed for sqlexec
18:00:19 listener-thread: err = -27002: oserr = 0: errstr = : No connections are allowed in Dynamic Server quiescent mode.
18:00:20 Physical Recovery Started.
18:00:23 Physical Recovery Complete: 320 Pages Restored.
18:00:23 Logical Recovery Started.
--
Wojtek Mitus
-----------
wm@biol.uni.wroc.pl
Hi,
When you are constructing the string are you ensuring that the trailing
spaces are being clipped ? This could be a possible reason for the
string length to exceed 255 chars.
cheers
In article <80ut9t$f78$1@panorama.pwr.wroc.pl>,
wm@biol.uni.wroc.pl wrote:
> Hi
>
> We have a problem with stored procedure that is called via onsoctcp
> network connection. This procedure is constructing a string that
> is passed to the SYSTEM command which executes a *.4ge program with
> some parameters. This procedure is acting strange - it is loaded into
> the database, and then some tests are performed - everything works
great.
> The next morning some more testing is done, and the procedure crashes
with
> exception -881. When it is reloaded via dbaccess , and then executed
from it
> too - everything starts working again. If we just reload the
procedure, it's
> still returning -881, we must call it once from dbaccess, not from our
client
> program to get it to work again.
>
> All that we know is that this -881 happens when the SYSTEM() is
called.
>
> The other problem we have is that our online crashes EVERY time whe we
try
> to use SET DEBUG FILE TO , and TRACE ON commands in stored procedures.
>
> The system we working on is T500 with HP-UX 10.30 and Online 7.30
> Maybe someone can help ?
>
> thanks
>
> --
> Wojtek Mitus
> -----------
> wm@biol.uni.wroc.pl
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <810cet$pnm$1@panorama.pwr.wroc.pl>, wm@biol.uni.wroc.pl
writes
>David Williams <djw@smooth1.demon.co.uk> wrote:
>> What is -881?
>
>Hi
>
>this is finderr -881:
>
>The TRIM function returned a string whose length did not span a range
>from 1 to 255 characters. The TRIM function returns a VARCHAR string.
>A VARCHAR string must have a length that ranges from 1 character to 255
>characters. Check that the TRIM function returns strings whose length
>is within that range.
>
>
>>>The other problem we have is that our online crashes EVERY time whe we try
>>>to use SET DEBUG FILE TO , and TRACE ON commands in stored procedures.
>>>
>> Do you get an af file? What is in the online.log ?
>
>Yep. An af file is about 500 kbytes, so i can't include it here. Online.log
>looks like that:
>
What is the stack trace in the af file?
>17:36:28 Logical Log 4726 - Backup Completed
>17:38:14 Checkpoint Completed: duration was 10 seconds.
>17:41:21 Assert Failed: No Exception Handler
>17:41:21 Informix Dynamic Server Version 7.30.UC7
>17:41:21 Who: Session(32709, promak@nt_work_2, 145, 0)
> Thread(52251, sqlexec, 0, 3)
> File: mtex.c Line: 314
>17:41:21 Results: Exception Caught. Type: MT_EX_OS, Context: mem
>17:41:21 Action: Please notify Informix Technical Support.
>17:41:21 stack trace for pid 1639 written to /opt/informix/af.cc1b8930
>17:43:26 Checkpoint Completed: duration was 8 seconds.
>17:45:16 ÖXÈÖ&9¬~ÍI, shmem.cc1b8930.0
>17:49:06 mtex.c, line 314, thread 52251, proc id 1639, No Exception Handler.
>17:49:33 PANIC: Attempting to bring system down>
>Tue Nov 16 18:00:10 1999
>
>18:00:10 Event alarms enabled. ALARMPROG = '/opt/informix/etc/log_full.sh'
>18:00:15 DR: DRAUTO is 0 (Off)
>18:00:16 Informix Dynamic Server Version 7.30.UC7 Software Serial Number>ACN#J165375
>18:00:19 (8) connection rejected - no calls allowed for sqlexec
>18:00:19 listener-thread: err = -27002: oserr = 0: errstr = : No connections>are allowed in Dynamic Server quiescent mode.
>18:00:20 Physical Recovery Started.
>18:00:23 Physical Recovery Complete: 320 Pages Restored.
>18:00:23 Logical Recovery Started.>
--
David Williams
David Williams <djw@smooth1.demon.co.uk> wrote:
> What is the stack trace in the af file?
I hope this is the right fragment of af:
17:41:21 Stack for thread: 52251 sqlexec
base: 0xd786d018
len: 135168
pc: 0x00000000
tos: 0xd786eb20
state: running
vp: 3
( 0) 0x003643d4 afstack + 0x124 [/opt/informix/bin/oninit]
( 1) 0x00363c78 afhandler + 0x630 [/opt/informix/bin/oninit]
( 2) 0x003635fc afcrash_interface + 0xa4 [/opt/informix/bin/oninit]
( 3) 0x00365354 mt_ex_throw_sig + 0x254 [/opt/informix/bin/oninit]
( 4) 0x0003545c afsig_segv + 0x2c [/opt/informix/bin/oninit]
( 5) 0xc0140630 _sigreturn [/usr/lib/libc.1]
( 6) 0xc009f598 free + 0x218 [/usr/lib/libc.1]
( 7) 0x0033a8cc gcvfprintf + 0x2cc [/opt/informix/bin/oninit]
( 8) 0x0010779c sfprintf + 0x84 [/opt/informix/bin/oninit]
( 9) 0x000684e0 print_value + 0x30 [/opt/informix/bin/oninit]
(10) 0x00062368 ip_evalexpr + 0x3d8 [/opt/informix/bin/oninit]
(11) 0x0006158c runproc + 0x3bc [/opt/informix/bin/oninit]
(12) 0x00066240 ip_curnext + 0xd8 [/opt/informix/bin/oninit]
(13) 0x00066064 ip_fetch + 0xac [/opt/informix/bin/oninit]
(14) 0x0013413c getrow + 0x44 [/opt/informix/bin/oninit]
(15) 0x001340d8 fetchrow + 0x128 [/opt/informix/bin/oninit]
(16) 0x00048174 exfetch + 0x2c [/opt/informix/bin/oninit]
(17) 0x0016b6d4 sq_nfetch + 0x204 [/opt/informix/bin/oninit]
(18) 0x000e6ac0 sqmain + 0x98 [/opt/informix/bin/oninit]
(19) 0x003658f0 startup + 0xa0 [/opt/informix/bin/oninit]
(20) 0x003657f0 mt_swap_threads + 0xdc [/opt/informix/bin/oninit]
(20) 0x003657f0 mt_swap_threads + 0xdc [/opt/informix/bin/oninit]
--
Wojtek Mitus
-----------
wm@biol.uni.wroc.pl
In article <8134a7$gan$1@panorama.pwr.wroc.pl>, wm@biol.uni.wroc.pl
writes
>David Williams <djw@smooth1.demon.co.uk> wrote:
>> What is the stack trace in the af file?
>
>I hope this is the right fragment of af:
>
>17:41:21 Stack for thread: 52251 sqlexec>
> base: 0xd786d018
> len: 135168
> pc: 0x00000000
> tos: 0xd786eb20
>state: running
> vp: 3
>
>( 0) 0x003643d4 afstack + 0x124 [/opt/informix/bin/oninit]
>( 1) 0x00363c78 afhandler + 0x630 [/opt/informix/bin/oninit]
>( 2) 0x003635fc afcrash_interface + 0xa4 [/opt/informix/bin/oninit]
>( 3) 0x00365354 mt_ex_throw_sig + 0x254 [/opt/informix/bin/oninit]
>( 4) 0x0003545c afsig_segv + 0x2c [/opt/informix/bin/oninit]
>( 5) 0xc0140630 _sigreturn [/usr/lib/libc.1]
>( 6) 0xc009f598 free + 0x218 [/usr/lib/libc.1]
>( 7) 0x0033a8cc gcvfprintf + 0x2cc [/opt/informix/bin/oninit]
>( 8) 0x0010779c sfprintf + 0x84 [/opt/informix/bin/oninit]
Printing a value..
>( 9) 0x000684e0 print_value + 0x30 [/opt/informix/bin/oninit]
>(10) 0x00062368 ip_evalexpr + 0x3d8 [/opt/informix/bin/oninit]
>(11) 0x0006158c runproc + 0x3bc [/opt/informix/bin/oninit]
Inside running a stored procedure
>(12) 0x00066240 ip_curnext + 0xd8 [/opt/informix/bin/oninit]
Inside a fetch next
>(13) 0x00066064 ip_fetch + 0xac [/opt/informix/bin/oninit]
>(14) 0x0013413c getrow + 0x44 [/opt/informix/bin/oninit]
>(15) 0x001340d8 fetchrow + 0x128 [/opt/informix/bin/oninit]
>(16) 0x00048174 exfetch + 0x2c [/opt/informix/bin/oninit]
>(17) 0x0016b6d4 sq_nfetch + 0x204 [/opt/informix/bin/oninit]
Part of an sql fetch statement
>(18) 0x000e6ac0 sqmain + 0x98 [/opt/informix/bin/oninit]
>(19) 0x003658f0 startup + 0xa0 [/opt/informix/bin/oninit]
>(20) 0x003657f0 mt_swap_threads + 0xdc [/opt/informix/bin/oninit]
>(20) 0x003657f0 mt_swap_threads + 0xdc [/opt/informix/bin/oninit]
Looks like a bug. Look at moving to 7.31.UC4-1
--
David Williams