SQL1131N DARI (Stored Procedure)

[N.V.Dev]

Hi,

I am trying to use the db2load API using C. During run-time below is
the error message thrown

call utils.load_table('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:db2inmt Node:000
PID:3194882(db2sysc 0) TID:1 Appid:none
base sys utilities sqleChildCrashHandler Probe:15

DiagData
0x00000001000087C8 : 4120 6E6F 6E2D 4544 5520 6368 696C 6420 A
non-EDU child
0x00000001000087D8 : 6372 6173 6865 642E
crashed.

2003-11-16-10.45.17.322507 Instance:db2inmt Node:000
PID:3194882(db2sysc 0) TID:1 Appid:none
base sys utilities sqleChildCrashHandler Probe:16

DiagData
0x0FFFFFFFFFFFDF44 : 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

[W Gemini]

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:

Hi,

I am trying to use the db2load API using C. During run-time below is
the error message thrown

call utils.load_table('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:db2inmt Node:000
PID:3194882(db2sysc 0) TID:1 Appid:none
base sys utilities sqleChildCrashHandler Probe:15

DiagData
0x00000001000087C8 : 4120 6E6F 6E2D 4544 5520 6368 696C 6420 A
non-EDU child
0x00000001000087D8 : 6372 6173 6865 642E
crashed.

2003-11-16-10.45.17.322507 Instance:db2inmt Node:000
PID:3194882(db2sysc 0) TID:1 Appid:none
base sys utilities sqleChildCrashHandler Probe:16

DiagData
0x0FFFFFFFFFFFDF44 : 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

[Knut Stolze]

W Gemini <wg*****@nowhere.com> wrote:

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.
On Windows, you should find the requested file under sqllib/db2 (or whatever
your instance is named).
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).

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]

Knut Stolze <st****@de.ibm.com> wrote in message news:<bp**********@fsuj29.rz.uni-jena.de>...

W Gemini <wg*****@nowhere.com> wrote:

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.

On Windows, you should find the requested file under sqllib/db2 (or whatever
your instance is named).

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

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.

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

0x09000000043CE790 : 4200FFE8: bc OPCD:16 BO:16 BI:0 BD:16378
AA:0 LK:0
0x09000000043CE794 : E8A40000: ld OPCD:58 RT:5 RA:4 D:0 XO:0
0x09000000043CE798 : 30E7FFF8: addic OPCD:12 RT:7 RA:7 D:65528
0x09000000043CE79C : 7CA95038: and OPCD:31 RT:5 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE7A0 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE7A4 : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE7A8 : 40820034: bc OPCD:16 BO:4 BI:2 BD:13 AA:0
LK:0
0x09000000043CE7AC : E9040009: ldu OPCD:58 RT:8 RA:4 D:2 XO:1

0x09000000043CE7B0 : F8A70009: stdu OPCD:62 RT:5 RA:7 D:2 XO:1

0x09000000043CE7B4 : 7D095038: and OPCD:31 RT:8 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE7B8 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE7BC : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE7C0 : 4082002C: bc OPCD:16 BO:4 BI:2 BD:11 AA:0
LK:0
0x09000000043CE7C4 : E8A40009: ldu OPCD:58 RT:5 RA:4 D:2 XO:1

*** End dump of instructions at point of failure ***
*** Start stack traceback ***

0x09000000043CE7B0 strcat + 0xB0
0x09000000043CE494 truncate + 0x29C
0x0900000009B16FD4 sqloInvokeFnArgs + 0xC4
0x0900000009F0A8BC sqlerRunRoutine__FP13sqleInvokerCBPi + 0x4DC
0x0900000009F0A184 sqlerDyload__FP13sqleInvokerCBPi + 0x17C
0x0900000009BE8538 sqlerFmpListener__FP17sqlcc_init_structP18sqlerFmp ProcThreadcsUs
+ 0x183C
0x000000010000245C main + 0x458

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

thanks in advance

[Sean McKeough]

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

N.V.Dev wrote:

Knut Stolze <st****@de.ibm.com> wrote in message news:<bp**********@fsuj29.rz.uni-jena.de>...

W Gemini <wg*****@nowhere.com> wrote:

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.

On Windows, you should find the requested file under sqllib/db2 (or whatever
your instance is named).

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

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.

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

0x09000000043CE790 : 4200FFE8: bc OPCD:16 BO:16 BI:0 BD:16378
AA:0 LK:0
0x09000000043CE794 : E8A40000: ld OPCD:58 RT:5 RA:4 D:0 XO:0
0x09000000043CE798 : 30E7FFF8: addic OPCD:12 RT:7 RA:7 D:65528
0x09000000043CE79C : 7CA95038: and OPCD:31 RT:5 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE7A0 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE7A4 : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE7A8 : 40820034: bc OPCD:16 BO:4 BI:2 BD:13 AA:0
LK:0
0x09000000043CE7AC : E9040009: ldu OPCD:58 RT:8 RA:4 D:2 XO:1

>0x09000000043CE7B0 : F8A70009: stdu OPCD:62 RT:5 RA:7 D:2 XO:1

0x09000000043CE7B4 : 7D095038: and OPCD:31 RT:8 RA:9 RB:10 XO:28
Rc:0
0x09000000043CE7B8 : 7D295014: addc OPCD:31 RT:9 RA:9 RB:10 OE:0
XO:10 Rc:0
0x09000000043CE7BC : 7D2C50F9: nor OPCD:31 RT:9 RA:12 RB:10
XO:124 Rc:1
0x09000000043CE7C0 : 4082002C: bc OPCD:16 BO:4 BI:2 BD:11 AA:0
LK:0
0x09000000043CE7C4 : E8A40009: ldu OPCD:58 RT:5 RA:4 D:2 XO:1

*** End dump of instructions at point of failure ***
*** Start stack traceback ***

0x09000000043CE7B0 strcat + 0xB0
0x09000000043CE494 truncate + 0x29C
0x0900000009B16FD4 sqloInvokeFnArgs + 0xC4
0x0900000009F0A8BC sqlerRunRoutine__FP13sqleInvokerCBPi + 0x4DC
0x0900000009F0A184 sqlerDyload__FP13sqleInvokerCBPi + 0x17C
0x0900000009BE8538 sqlerFmpListener__FP17sqlcc_init_structP18sqlerFmp ProcThreadcsUs
+ 0x183C
0x000000010000245C main + 0x458

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

thanks in advance

[Knut Stolze]

N.V.Dev <de***@yahoo.com> wrote:

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

below is the info
[...]
*** Start stack traceback ***

0x09000000043CE7B0 strcat + 0xB0
0x09000000043CE494 truncate + 0x29C
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??
0x0900000009B16FD4 sqloInvokeFnArgs + 0xC4
0x0900000009F0A8BC sqlerRunRoutine__FP13sqleInvokerCBPi + 0x4DC
0x0900000009F0A184 sqlerDyload__FP13sqleInvokerCBPi + 0x17C
0x0900000009BE8538
sqlerFmpListener__FP17sqlcc_init_structP18sqlerFmp ProcThreadcsUs + 0x183C
0x000000010000245C main + 0x458

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

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]

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.piActionString = (struct sqlchar *) malloc(sizeof(short)
+
strlen (pActionString) + 1);

8: if ( loadParms.piFileTypeMod != NULL )
9: {
10: strcpy( loadParms.piActionString->data, pActionString );
11: loadParms.piFileTypeMod->length = strlen(pActionString);
....
15: }
16: else
17: {
18: strcpy( sqludf_sqlstate, MEMORY_NOT_ALLOCATED_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.piActionString to stack instead of heap as below

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

loadParms.piActionString = (struct sqlchar *) &sql_char;
strcpy( loadParms.piActionString->data, pActionString );
loadParms.piFileTypeMod->length = strlen(pActionString);
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]

N.V.Dev <de***@yahoo.com> wrote:

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.piActionString = (struct sqlchar *) malloc(sizeof(short)
+
strlen (pActionString) + 1);
That's pretty obvious here: the calculation of the size for the memory
buffer above was not correct. I would change it thus:

loadParms.piActionString = (struct sqlchar *)malloc(
sizeof(struct sqlchar) + strlen(pActionString) + 1);
8: if ( loadParms.piFileTypeMod != NULL )
9: {
10: strcpy( loadParms.piActionString->data, pActionString );
11: loadParms.piFileTypeMod->length = strlen(pActionString);
....
15: }
16: else
17: {
18: strcpy( sqludf_sqlstate, MEMORY_NOT_ALLOCATED_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
That code doesn't fit with the stack trace. There, you have the problem in
a call to "strcat" not "strcpy".
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.piActionString to stack instead of heap as below

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

loadParms.piActionString = (struct sqlchar *) &sql_char;
strcpy( loadParms.piActionString->data, pActionString );
loadParms.piFileTypeMod->length = strlen(pActionString);
This still doesn't look very safe to me. What happens if the pActionString
exceeds the buffer size?

Alternative 1:

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

Alternative 2:

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

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

???

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

[N.V.Dev]

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