SQL1131N DARI (Stored Procedure)

**W Gemini** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

Do you have a trap file generated? (Should be in the form of t123456.000
under your sqllib/db2dump directory) SQL1131N means the fenced mode
process terminated abnormally. From the db2diag, it actually trapped and
thus should have generated a trap file. It would show us whether it
trapped in db2 or your stored procedure or in the load api. To be
honest, I am not sure whether you can use db2load api since no
connection is allowed in a C stored procedure and db2load might make a
connection (I don't know for sure).

N.V.Dev wrote:[color=blue]
> Hi,
>
> I am trying to use the db2load API using C. During run-time below is
> the error message thrown
>
> call utils.load_tabl e('util.temp')
> SQL1131N DARI (Stored Procedure) process has been terminated
> abnormally.
> SQLSTATE=38503
>
> and below is the db2diag.log
>
> 2003-11-16-10.45.17.318775 Instance:db2inm t Node:000
> PID:3194882(db2 sysc 0) TID:1 Appid:none
> base sys utilities sqleChildCrashH andler Probe:15
>
> DiagData
> 0x0000000100008 7C8 : 4120 6E6F 6E2D 4544 5520 6368 696C 6420 A
> non-EDU child
> 0x0000000100008 7D8 : 6372 6173 6865 642E
> crashed.
>
> 2003-11-16-10.45.17.322507 Instance:db2inm t Node:000
> PID:3194882(db2 sysc 0) TID:1 Appid:none
> base sys utilities sqleChildCrashH andler Probe:16
>
> DiagData
> 0x0FFFFFFFFFFFD F44 : 0x00082056 .. V
>
>
> this code is running on AIX 5.2.0.0 -- 64 bits, DB2 8.1 FixPak 2.
>
> Any help is appreciated.
> Thanks,
> Dev[/color]

**Knut Stolze** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

W Gemini <wgemini@nowher e.com> wrote:
[color=blue]
> Do you have a trap file generated? (Should be in the form of t123456.000
> under your sqllib/db2dump directory) SQL1131N means the fenced mode
> process terminated abnormally. From the db2diag, it actually trapped and
> thus should have generated a trap file. It would show us whether it
> trapped in db2 or your stored procedure or in the load api.[/color]

On Windows, you should find the requested file under sqllib/db2 (or whatever
your instance is named).
[color=blue]
> To be
> honest, I am not sure whether you can use db2load api since no
> connection is allowed in a C stored procedure and db2load might make a
> connection (I don't know for sure).[/color]

You can do it, for sure. ;-) The C stored procedure already has a
connection inheritted from the SQL session in which the procedure was
called.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

**N.V.Dev** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

Knut Stolze <stolze@de.ibm. com> wrote in message news:<bp9tq5$ch d$3@fsuj29.rz.u ni-jena.de>...[color=blue]
> W Gemini <wgemini@nowher e.com> wrote:
>[color=green]
> > Do you have a trap file generated? (Should be in the form of t123456.000
> > under your sqllib/db2dump directory) SQL1131N means the fenced mode
> > process terminated abnormally. From the db2diag, it actually trapped and
> > thus should have generated a trap file. It would show us whether it
> > trapped in db2 or your stored procedure or in the load api.[/color]
>
> On Windows, you should find the requested file under sqllib/db2 (or whatever
> your instance is named).
>[color=green]
> > To be
> > honest, I am not sure whether you can use db2load api since no
> > connection is allowed in a C stored procedure and db2load might make a
> > connection (I don't know for sure).[/color]
>
> You can do it, for sure. ;-) The C stored procedure already has a
> connection inheritted from the SQL session in which the procedure was
> called.[/color]

Thanks all to direct me to get the trap file... Yes, i have the
file...runs upto 1324 lines...

below is the info

*** Start dump of instructions at point of failure ***

0x09000000043CE 790 : 4200FFE8: bc OPCD:16 BO:16 BI:0 BD:16378
AA:0 LK:0
0x09000000043CE 794 : E8A40000: ld OPCD:58 RT:5 RA:4 D:0 XO:0
0x09000000043CE 798 : 30E7FFF8: addic OPCD:12 RT:7 RA:7 D:65528
0x09000000043CE 79C : 7CA95038: and OPCD:31 RT:5 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE 7A0 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE 7A4 : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE 7A8 : 40820034: bc OPCD:16 BO:4 BI:2 BD:13 AA:0
LK:0
0x09000000043CE 7AC : E9040009: ldu OPCD:58 RT:8 RA:4 D:2 XO:1[color=blue][color=green][color=darkred]
>>>> 0x09000000043CE 7B0 : F8A70009: stdu OPCD:62 RT:5 RA:7 D:2 XO:1[/color][/color][/color]
0x09000000043CE 7B4 : 7D095038: and OPCD:31 RT:8 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE 7B8 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE 7BC : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE 7C0 : 4082002C: bc OPCD:16 BO:4 BI:2 BD:11 AA:0
LK:0
0x09000000043CE 7C4 : E8A40009: ldu OPCD:58 RT:5 RA:4 D:2 XO:1

*** End dump of instructions at point of failure ***

*** Start stack traceback ***

0x09000000043CE 7B0 strcat + 0xB0
0x09000000043CE 494 truncate + 0x29C
0x0900000009B16 FD4 sqloInvokeFnArg s + 0xC4
0x0900000009F0A 8BC sqlerRunRoutine __FP13sqleInvok erCBPi + 0x4DC
0x0900000009F0A 184 sqlerDyload__FP 13sqleInvokerCB Pi + 0x17C
0x0900000009BE8 538 sqlerFmpListene r__FP17sqlcc_in it_structP18sql erFmpProcThread csUs
+ 0x183C
0x0000000100002 45C main + 0x458

*** End stack traceback ***

while the same code when converted to stand-alone esql-c works fine
without any error message.....whi le converting this to procedure gives
memory flow error...
any insights....

thanks in advance

**Sean McKeough** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

It's trapping in your stored procedure, as you can see from the callstack.

N.V.Dev wrote:
[color=blue]
> Knut Stolze <stolze@de.ibm. com> wrote in message news:<bp9tq5$ch d$3@fsuj29.rz.u ni-jena.de>...
>[color=green]
>>W Gemini <wgemini@nowher e.com> wrote:
>>
>>[color=darkred]
>>>Do you have a trap file generated? (Should be in the form of t123456.000
>>>under your sqllib/db2dump directory) SQL1131N means the fenced mode
>>>process terminated abnormally. From the db2diag, it actually trapped and
>>>thus should have generated a trap file. It would show us whether it
>>>trapped in db2 or your stored procedure or in the load api.[/color]
>>
>>On Windows, you should find the requested file under sqllib/db2 (or whatever
>>your instance is named).
>>
>>[color=darkred]
>>>To be
>>>honest, I am not sure whether you can use db2load api since no
>>>connection is allowed in a C stored procedure and db2load might make a
>>>connection (I don't know for sure).[/color]
>>
>>You can do it, for sure. ;-) The C stored procedure already has a
>>connection inheritted from the SQL session in which the procedure was
>>called.[/color]
>
>
>
>
> Thanks all to direct me to get the trap file... Yes, i have the
> file...runs upto 1324 lines...
>
> below is the info
>
> *** Start dump of instructions at point of failure ***
>
> 0x09000000043CE 790 : 4200FFE8: bc OPCD:16 BO:16 BI:0 BD:16378
> AA:0 LK:0
> 0x09000000043CE 794 : E8A40000: ld OPCD:58 RT:5 RA:4 D:0 XO:0
> 0x09000000043CE 798 : 30E7FFF8: addic OPCD:12 RT:7 RA:7 D:65528
> 0x09000000043CE 79C : 7CA95038: and OPCD:31 RT:5 RA:9 RB:10 XO:28
> Rc:0
> 0x09000000043CE 7A0 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
> XO:10 Rc:0
> 0x09000000043CE 7A4 : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
> XO:124 Rc:1
> 0x09000000043CE 7A8 : 40820034: bc OPCD:16 BO:4 BI:2 BD:13 AA:0
> LK:0
> 0x09000000043CE 7AC : E9040009: ldu OPCD:58 RT:8 RA:4 D:2 XO:1
>[color=green][color=darkred]
>>>>>0x09000000 043CE7B0 : F8A70009: stdu OPCD:62 RT:5 RA:7 D:2 XO:1[/color][/color]
>
> 0x09000000043CE 7B4 : 7D095038: and OPCD:31 RT:8 RA:9 RB:10 XO:28
> Rc:0
> 0x09000000043CE 7B8 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
> XO:10 Rc:0
> 0x09000000043CE 7BC : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
> XO:124 Rc:1
> 0x09000000043CE 7C0 : 4082002C: bc OPCD:16 BO:4 BI:2 BD:11 AA:0
> LK:0
> 0x09000000043CE 7C4 : E8A40009: ldu OPCD:58 RT:5 RA:4 D:2 XO:1
>
> *** End dump of instructions at point of failure ***
>
>
> *** Start stack traceback ***
>
> 0x09000000043CE 7B0 strcat + 0xB0
> 0x09000000043CE 494 truncate + 0x29C
> 0x0900000009B16 FD4 sqloInvokeFnArg s + 0xC4
> 0x0900000009F0A 8BC sqlerRunRoutine __FP13sqleInvok erCBPi + 0x4DC
> 0x0900000009F0A 184 sqlerDyload__FP 13sqleInvokerCB Pi + 0x17C
> 0x0900000009BE8 538 sqlerFmpListene r__FP17sqlcc_in it_structP18sql erFmpProcThread csUs
> + 0x183C
> 0x0000000100002 45C main + 0x458
>
> *** End stack traceback ***
>
>
> while the same code when converted to stand-alone esql-c works fine
> without any error message.....whi le converting this to procedure gives
> memory flow error...
> any insights....
>
> thanks in advance[/color]

**Knut Stolze** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

N.V.Dev <devnv@yahoo.co m> wrote:
[color=blue]
> Thanks all to direct me to get the trap file... Yes, i have the
> file...runs upto 1324 lines...
>
> below is the info
>[/color]
[...][color=blue]
>
> *** Start stack traceback ***
>
> 0x09000000043CE 7B0 strcat + 0xB0
> 0x09000000043CE 494 truncate + 0x29C[/color]

Have a look at your code in the "truncate" function. Somewhere, you are
calling "strcat", and either you have some NULL or invalid pointers or some
memory area is just too small.

Maybe you can post the code so that we all can have a look at it??
[color=blue]
> 0x0900000009B16 FD4 sqloInvokeFnArg s + 0xC4
> 0x0900000009F0A 8BC sqlerRunRoutine __FP13sqleInvok erCBPi + 0x4DC
> 0x0900000009F0A 184 sqlerDyload__FP 13sqleInvokerCB Pi + 0x17C
> 0x0900000009BE8 538
> sqlerFmpListene r__FP17sqlcc_in it_structP18sql erFmpProcThread csUs + 0x183C
> 0x0000000100002 45C main + 0x458
>
> *** End stack traceback ***
>
>
> while the same code when converted to stand-alone esql-c works fine
> without any error message.....whi le converting this to procedure gives
> memory flow error...
> any insights....[/color]

Yes, I have an explanation: you are just lucky that your code doesn't crash
when running stand-alone.
I have seen something like that before where a bad estimate on the needed
memory was done. Things worked--by chance--when run standalone, but it
caused severe memory corruptions nevertheless. Everything flew apart in a
DB2 UDF because the memory corruption actually hit things it shouldn't
have.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

**N.V.Dev** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

Hey,

Thanks for the feedback. After playing a lot, at last, got it work.

1: # include <db2ApiDf.h>

.....

5: db2LoadStruct loadParms;
6: char pActionString[ 255 ] ;

7: loadParms.piAct ionString = (struct sqlchar *) malloc(sizeof(s hort)
+
strlen (pActionString) + 1);

8: if ( loadParms.piFil eTypeMod != NULL )
9: {
10: strcpy( loadParms.piAct ionString->data, pActionString );
11: loadParms.piFil eTypeMod->length = strlen(pActionS tring);
....
15: }
16: else
17: {
18: strcpy( sqludf_sqlstate , MEMORY_NOT_ALLO CATED_SQLSTATE );
19: strcpy( sqludf_msgtext, strerror( errno ) );
20: }

Line numbers used are just to point not 'as is' in the program.

Line 10 was the cause of faliure. Checked out in db2ApiDf.h, sql.h
which has below defintion

db2LoadStruct is defined in db2ApiDf.h
piActionString is type of struct sqlchar *

below are members of sqlchar defined in sql.h :

SQL_STRUCTURE sqlchar
{
short length;
_SQLOLDCHAR data[1];
}

Tweak:

Defined another structure same as sqlchar locally and pointed
loadParms.piAct ionString to stack instead of heap as below

SQL_STRUCTURE
{
short length;
_SQLOLDCHAR data[ 1000 ];
} sql_char;

loadParms.piAct ionString = (struct sqlchar *) &sql_char;
strcpy( loadParms.piAct ionString->data, pActionString );
loadParms.piFil eTypeMod->length = strlen(pActionS tring);

voila, this worked and did not fail.

while, i am still not able to understand why is data declared as data[
1 ] instead not with a char * or may be data[ 1000 ].
Hope i my understanding is not wrong.

So, now how does DB2 gel with C to handle memory allocated in heap.

I need to create another sample just as same as the one defined in
header files and test it. Hope this would give an insight.

Listen, the same utility when tested in 32 bit using malloc() worked
fine. Wondering there should be some other things to take care to work
in 64 bits.

Any insight, or views or remarks as usual would be helpful in
learning.

Thanks again,
Dev

**Knut Stolze** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

N.V.Dev <devnv@yahoo.co m> wrote:
[color=blue]
> Hey,
>
> Thanks for the feedback. After playing a lot, at last, got it work.
>
> 1: # include <db2ApiDf.h>
>
> ....
>
> 5: db2LoadStruct loadParms;
> 6: char pActionString[ 255 ] ;
>
> 7: loadParms.piAct ionString = (struct sqlchar *) malloc(sizeof(s hort)
> +
> strlen (pActionString) + 1);[/color]

That's pretty obvious here: the calculation of the size for the memory
buffer above was not correct. I would change it thus:

loadParms.piAct ionString = (struct sqlchar *)malloc(
sizeof(struct sqlchar) + strlen(pActionS tring) + 1);
[color=blue]
> 8: if ( loadParms.piFil eTypeMod != NULL )
> 9: {
> 10: strcpy( loadParms.piAct ionString->data, pActionString );
> 11: loadParms.piFil eTypeMod->length = strlen(pActionS tring);
> ....
> 15: }
> 16: else
> 17: {
> 18: strcpy( sqludf_sqlstate , MEMORY_NOT_ALLO CATED_SQLSTATE );
> 19: strcpy( sqludf_msgtext, strerror( errno ) );
> 20: }
>
> Line numbers used are just to point not 'as is' in the program.
>
>
> Line 10 was the cause of faliure. Checked out in db2ApiDf.h, sql.h
> which has below defintion[/color]

That code doesn't fit with the stack trace. There, you have the problem in
a call to "strcat" not "strcpy".
[color=blue]
> db2LoadStruct is defined in db2ApiDf.h
> piActionString is type of struct sqlchar *
>
> below are members of sqlchar defined in sql.h :
>
> SQL_STRUCTURE sqlchar
> {
> short length;
> _SQLOLDCHAR data[1];
> }
>
> Tweak:
>
> Defined another structure same as sqlchar locally and pointed
> loadParms.piAct ionString to stack instead of heap as below
>
> SQL_STRUCTURE
> {
> short length;
> _SQLOLDCHAR data[ 1000 ];
> } sql_char;
>
> loadParms.piAct ionString = (struct sqlchar *) &sql_char;
> strcpy( loadParms.piAct ionString->data, pActionString );
> loadParms.piFil eTypeMod->length = strlen(pActionS tring);[/color]

This still doesn't look very safe to me. What happens if the pActionString
exceeds the buffer size?

Alternative 1:

loadParms.piAct ionString = (struct sqlchar *) &sql_char;
strncpy( loadParms.piAct ionString->data, pActionString,
sizeof(sql_char .data)-1);

Alternative 2:

if (sizeof(sqlchar .data) >= strlen(pActionS tring)) {
// handle error
}
strcpy( loadParms.piAct ionString->data, pActionString);

[color=blue]
> while, i am still not able to understand why is data declared as data[
> 1 ] instead not with a char * or may be data[ 1000 ].[/color]

char data[1000] would possibly waste a lot of space if it is not need (often
you probably only need a few bytes.

Using a "char *" says that you will store a pointer there. The char
char[1], on the other hand, implies such a layout:

+----------------+------------+
| length (short) | data.... |
+----------------+------------+

without wasting memory. But now you have to allocate enough memory to (a)
fit the structure, and (b) the actual character data.
[color=blue]
> So, now how does DB2 gel with C to handle memory allocated in heap.[/color]

???
[color=blue]
> I need to create another sample just as same as the one defined in
> header files and test it. Hope this would give an insight.
>
> Listen, the same utility when tested in 32 bit using malloc() worked
> fine. Wondering there should be some other things to take care to work
> in 64 bits.[/color]

???

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

**N.V.Dev** · Nov 12 '05, 05:52 AM

Re: SQL1131N DARI (Stored Procedure)

hey,

thanks for the explanation and would follow the ways which you had
mentioned. this would enable the program to be more sturdy.

i really agree with your point with respect to strncpy() and now
understood why it is defined with char[1].

thanks again

would come up again should i face anything wierd like this.

thanks, bunches,
dev

SQL1131N DARI (Stored Procedure)

SQL1131N DARI (Stored Procedure)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment