php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16729 ORA-01013 and ORA-03120
Submitted: 2002-04-22 07:11 UTC Modified: 2002-04-23 06:32 UTC
From: fernando dot trindade at oni dot pt Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.0CVS-2002-04-22 OS: RedHat Linux 2.4.9-31
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
42 - 12 = ?
Subscribe to this entry?

 
 [2002-04-22 07:11 UTC] fernando dot trindade at oni dot pt



Hello all.
We found a problem related with connecting Oracle 9i with php.

Environment Description:

Processor:		Intel(R) Pentium(R) III CPU family      1133MHz
S.O.			Linux 2.4.9-31 (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98))

modules:		php-4.0.6-7
			php-ldap-4.0.6-7
			kernel-2.4.9-31	
			kernel-headers-2.4.9-31



When in an environment with

these, don't work!!!		these, it works!!!

php-4.0.6-7			php-4.0.6-7
php-ldap-4.0.6-7		php-ldap-4.0.6-7

kernel-2.4.9-31			kernel-2.4.7-10
kernel-headers-2.4.9-31		kernel-headers-2.4.7-10

				php-devel-4.0.6-7
				php-imap-4.0.6-7
				php-manual-4.0.6-7
				php-mysql-4.0.6-7
				php-odbc-4.0.6-7
				php-pgsql-4.0.6-7






Error Description:

We get this message in the browser window:
...................................................................
Error while trying to retrieve text for error ORA-03120 

Clarify Execute: Rolling Back!
Query Causing the Error: select DESCRIPTION, X_PAYMENT_TYPE from TABLE_PART_NUM where S_DOMAIN = 'PRICE PLAN' and X_EFFECTIVE_DATE <= sysdate and X_EXPIRATION_DATE >= sysdate
....................................................................


The error ORA-03120 is :
two task conversion routine: Integer overflow

Cause: An integer value in an internal Oracle structure overflowed when being sent or received over an heterogeneous connection. This can happen when an invalid buffer length or too great a row count is specified. It usually indicates a bug in the user application.

Action: Check parameters to oracle calls. If the problem recurs, reduce all integer parameters, column values NOT included, to less than 32767.



Besides that, the connection drop without reason while querying the database as we can see by the packet sniffing described below.



Sometimes this error does not happen, but most of the times it does. 
This is not an "on-stress error".
The main problem seems to be connected with some sort of "missunderstood" request, because if we capture the packets transmitted we find something like:



-----------------   This is a quite normal behaviour ---------------------------------
First there is a query string sent form machine X to machine Y, requesting a reply for the query


201   0.00024 xxxxxxxxxxxxx -> yyyyyyyyyyy       TCP D=1521 S=40244     
Ack=2538076455 bSeq=1935976453 Len=246 Win=10812 Options=<nop,nop,tstamp 17585030 144445375>

	   0: 0800 20ec 1550 0002 55c7 1ed3 0800 4500    .. ..P..U.....E.
	  16: 012a cfbc 4000 4006 f9b7 ac13 8c1c ac13    .*..@.@.........
	  32: 8c16 9d34 05f1 7364 a805 9747 f927 8018    ...4..sd...G.'..
	  48: 2a3c 368d 0000 0101 080a 010c 5386 089c    *<6.........S...
	  64: 0fbf 00f6 0000 0600 0000 0000 035e 0a02    .............^..
	  80: 8161 0001 01bf 0101 0c00 0100 0101 0000    .a..............
	  96: 0000 0000 0001 fe40 7365 6c65 6374 2058    .......@select X
	 112: 5f41 5454 525f 494e 5354 3258 5f41 5454    _ATTR_INST2X_ATT
	 128: 525f 4445 4620 6672 6f6d 2054 4142 4c45    R_DEF from TABLE
	 144: 5f58 5f41 5454 525f 494e 5354 2c20 5441    _X_ATTR_INST, TA
	 160: 424c 455f 585f 4154 4054 525f 4445 4620    BLE_X_AT@TR_DEF 
	 176: 7768 6572 6520 585f 4154 5452 5f49 4e53    where X_ATTR_INS
	 192: 5432 4d4f 445f 4c45 5645 4c20 3d20 3236    T2MOD_LEVEL = 26
	 208: 3834 3335 3436 3920 616e 6420 585f 4445    8435469 and X_DE
	 224: 4641 554c 5420 3d20 273f 4154 5452 4942    FAULT = '?ATTRIB
	 240: 5554 4553 2720 616e 6420 585f 4154 5452    UTES' and X_ATTR
	 256: 5f49 4e53 5432 585f 4154 5452 5f44 4546    _INST2X_ATTR_DEF
	 272: 203d 2054 4142 4c45 5f58 5f41 5454 525f     = TABLE_X_ATTR_
	 288: 4445 462e 4f42 4a49 4400 0101 0000 0000    DEF.OBJID.......
	 304: 0000 0101 0000 0000                        ........

Then, the Y machine responds with the row or, in this case, with the indication that there is no data to display:

202   0.01326       yyyyyyyyy -> xxxxxxxxxxx TCP D=40244 S=1521     
Ack=1935976699 Seq=2538076455 Len=155 Win=24616 Options=<nop,nop,tstamp 144445376 17585030>

	   0: 0002 55c7 1ed3 0800 20ec 1550 0800 4500    ..U..... ..P..E.
	  16: 00cf 1d5c 4000 4006 ac73 ac13 8c16 ac13    ...\@.@..s......
	  32: 8c1c 05f1 9d34 9747 f927 7364 a8fb 8018    .....4.G.'sd.?..
	  48: 6028 3494 0000 0101 080a 089c 0fc0 010c    `(4.............
	  64: 5386 009b 0000 0600 0000 0000 101d a66d    S..............m
	  80: 2dc6 0000 0003 82ef 3878 0000 7866 0413    -.......8x..xf..
	  96: 0d39 2100 0000 7800 0000 0101 1601 0143    .9!...x........C
	 112: 0200 0000 0116 0000 0000 0000 0116 0116    ................
	 128: 1658 5f41 5454 525f 494e 5354 3258 5f41    .X_ATTR_INST2X_A
	 144: 5454 525f 4445 4600 0001 0707 7866 0413    TTR_DEF.....xf..
	 160: 0e15 1c04 0002 057b 0000 0102 0123 0300    .......{.....#..
	 176: 0000 0000 0000 0000 0000 000a 0001 0100    ................
	 192: 0000 0019 4f52 412d 3031 3430 333a 206e    ....ORA-01403: n
	 208: 6f20 6461 7461 2066 6f75 6e64 0a           o data found.

---------------------------------------------------------------------------------------

But sometimes, and JUST with the environment described as not working, something different happens:


The X machine request for data...

5770   0.00102 xxxxxxxxxx -> yyyyyyyyy       TCP D=1521 S=40246     
Ack=2997080191 Seq=1983973792 Len=214 Win=9010 Options=<nop,nop,tstamp 17590367 144450713>

	   0: 0800 20ec 1550 0002 55c7 1ed3 0800 4500    .. ..P..U.....E.
	  16: 010a 698e 4000 4006 6006 ac13 8c1c ac13    ..i.@.@.`.......
	  32: 8c16 9d36 05f1 7641 09a0 b2a3 d07f 8018    ...6..vA........
	  48: 2332 9bd3 0000 0101 080a 010c 685f 089c    #2..........h_..
	  64: 2499 00d6 0000 0600 0000 0000 116b 0401    $............k..
	  80: 0e02 010b 0101 035e 0502 8161 0001 0195    .......^...a....
	  96: 0101 0c00 0100 0101 0000 0000 0000 0001    ................
	 112: fe40 7365 6c65 6374 2044 4553 4352 4950    ?@select DESCRIP
	 128: 5449 4f4e 2c20 585f 5041 594d 454e 545f    TION, X_PAYMENT_
	 144: 5459 5045 2066 726f 6d20 5441 424c 455f    TYPE from TABLE_
	 160: 5041 5254 5f4e 554d 2077 6865 7265 2053    PART_NUM where S
	 176: 5f44 404f 4d41 494e 203d 2027 5052 4943    _D@OMAIN = 'PRIC
	 192: 4520 504c 414e 2720 616e 6420 585f 4546    E PLAN' and X_EF
	 208: 4645 4354 4956 455f 4441 5445 203c 3d20    FECTIVE_DATE <= 
	 224: 7379 7364 6174 6520 616e 6420 585f 4558    sysdate and X_EX
	 240: 5049 5215 4154 494f 4e5f 4441 5445 203e    PIR.ATION_DATE >
	 256: 3d20 7379 7364 6174 6500 0101 0000 0000    = sysdate.......
	 272: 0000 0101 0000 0000                        ........


The Y machine responds with the first row....

5771   0.00183       yyyyyyyyy -> xxxxxxxxxx TCP D=40246 S=1521     
Ack=1983974006 Seq=2997080191 Len=214 Win=24616 Options=<nop,nop,tstamp 144450713 17590367>

	   0: 0002 55c7 1ed3 0800 20ec 1550 0800 4500    ..U..... ..P..E.
	  16: 010a 2912 4000 4006 a082 ac13 8c16 ac13    ..).@.@.........
	  32: 8c1c 05f1 9d36 b2a3 d07f 7641 0a76 8018    .....6....vA.v..
	  48: 6028 6ce8 0000 0101 080a 089c 2499 010c    `(l.........$...
	  64: 685f 00d6 0000 0600 0000 0000 101d 156d    h_.............m
	  80: 8802 0000 0003 830e eac0 0000 7866 0413    ............xf..
	  96: 0d39 1e00 0000 7d00 0000 0402 0113 0102    .9....}.........
	 112: 4301 8000 0001 ff00 0000 0001 2e01 010b    C...............
	 128: 010b 0b44 4553 4352 4950 5449 4f4e 0000    ...DESCRIPTION..
	 144: 0180 0000 0114 0000 0000 012e 0101 0e01    ................
	 160: 0e0e 585f 5041 594d 454e 545f 5459 5045    ..X_PAYMENT_TYPE
	 176: 0000 0107 0778 6604 130e 1616 0602 0102    .....xf.........
	 192: 0001 0100 0000 0714 5461 7269 66e1 7269    ........Tarif.ri
	 208: 6f20 4469 6772 6573 7369 7665 0000 0850    o Digressive...P
	 224: 7265 2d70 6167 6f00 0008 0104 0458 3505    re-pago......X5.
	 240: 6502 02c2 0101 0102 0000 0401 0100 0000    e...............
	 256: 0101 0003 0000 0000 0000 0000 0000 0000    ................
	 272: 0500 0101 0000 0000                        ........


Some data is transferred....

5772   0.00037 xxxxxxxxxx -> yyyyyyyyy       TCP D=1521 S=40246     
Ack=2997080405 Seq=1983974006 Len=1 Win=9010 Options=<nop,nop,tstamp 17590367 144450713>

	   0: 0800 20ec 1550 0002 55c7 1ed3 0800 4500    .. ..P..U.....E.
	  16: 0035 698f 4000 4006 60da ac13 8c1c ac13    .5i.@.@.`.......
	  32: 8c16 9d36 05f1 7641 0a76 b2a3 d155 8038    ...6..vA.v...U.8
	  48: 2332 838e 0001 0101 080a 010c 685f 089c    #2..........h_..
	  64: 2499 21                                    $.!

5773   0.00005 xxxxxxxxxx -> yyyyyyyyy       TCP D=1521 S=40246     
Ack=2997080405 Seq=1983974007 Len=11 Win=9010 Options=<nop,nop,tstamp 17590367 144450713>

	   0: 0800 20ec 1550 0002 55c7 1ed3 0800 4500    .. ..P..U.....E.
	  16: 003f 6990 4000 4006 60cf ac13 8c1c ac13    .?i.@.@.`.......
	  32: 8c16 9d36 05f1 7641 0a77 b2a3 d155 8018    ...6..vA.w...U..
	  48: 2332 9599 0000 0101 080a 010c 685f 089c    #2..........h_..
	  64: 2499 000b 0000 0c00 0000 0100 02           $............

5774   0.00002       yyyyyyyyy -> xxxxxxxxxx TCP D=40246 S=1521     
Ack=1983974018 Seq=2997080405 Len=0 Win=24616 Options=<nop,nop,tstamp 144450713 17590367>

	   0: 0002 55c7 1ed3 0800 20ec 1550 0800 4500    ..U..... ..P..E.
	  16: 0034 2913 4000 4006 a157 ac13 8c16 ac13    .4).@.@..W......
	  32: 8c1c 05f1 9d36 b2a3 d155 7641 0a82 8010    .....6...UvA....
	  48: 6028 67b6 0000 0101 080a 089c 2499 010c    `(g.........$...
	  64: 685f                                       h_

5775   0.00016       yyyyyyyyy -> xxxxxxxxxx TCP D=40246 S=1521     
Ack=1983974018 Seq=2997080405 Len=11 Win=24616 Options=<nop,nop,tstamp 144450713 17590367>

	   0: 0002 55c7 1ed3 0800 20ec 1550 0800 4500    ..U..... ..P..E.
	  16: 003f 2914 4000 4006 a14b ac13 8c16 ac13    .?).@.@..K......
	  32: 8c1c 05f1 9d36 b2a3 d155 7641 0a82 8018    .....6...UvA....
	  48: 6028 5898 0000 0101 080a 089c 2499 010c    `(X.........$...
	  64: 685f 000b 0000 0c00 0000 0100 02           h_...........


And then, the Y machine responds with a "ORA-01013" without real user (or code) intervention!!!!

5776   0.00024       yyyyyyyyy -> xxxxxxxxxx TCP D=40246 S=1521     
Ack=1983974018 Seq=2997080416 Len=97 Win=24616 Options=<nop,nop,tstamp 144450714 17590367>

	   0: 0002 55c7 1ed3 0800 20ec 1550 0800 4500    ..U..... ..P..E.
	  16: 0095 2915 4000 4006 a0f4 ac13 8c16 ac13    ..).@.@.........
	  32: 8c1c 05f1 9d36 b2a3 d160 7641 0a82 8018    .....6...`vA....
	  48: 6028 271c 0000 0101 080a 089c 249a 010c    `('.........$...
	  64: 685f 0061 0000 0600 0000 0000 0401 0102    h_.a............
	  80: 03f5 0000 0101 0003 0000 0000 0000 0000    ................
	  96: 0000 0000 0500 0101 0000 0000 364f 5241    ............6ORA
	 112: 2d30 3130 3133 3a20 7573 6572 2072 6571    -01013: user req
	 128: 7565 7374 6564 2063 616e 6365 6c20 6f66    uested cancel of
	 144: 2063 7572 7265 6e74 206f 7065 7261 7469     current operati
	 160: 6f6e 0a                                    on.

---------------------------------------------------------------------------------------------

Thanks a lot for your help :o)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-22 11:49 UTC] thies@php.net
please send me a short self-contained testcase that shows 
your problem! 
 
 [2002-04-22 11:59 UTC] fernando dot trindade at oni dot pt
Sorry, it is not possible to send a small testcase... I would have to send the database, heh...
Also it is an environment a little bit strange... I just made an exact copy of the machine where it works and now...
it NEVER works!

There is, like I said, a machine that has the php code and a conection to an Oracle db that always works... There is 
this "bugged" machine where sometimes (around 30%) it results an error... and now, an exact copy of the environment from the first machine (where it allways work) just doesn't work at all....

I'm getting really said with all this...
:(
 [2002-04-22 12:56 UTC] fernando dot trindade at oni dot pt
Ok, now we got it!

Seems that the problem was that the Oracle installation had a NLS_Lang set to P15 while the Oracle Client had it set to P1.

Now we set both the NLS_Lang to P15 and it works smoothly.


So, Oracle Server was using some kind of buffer for the translation of the character set!

When reaching for that memory space during the query process, somehow it would cause a buffer overflow in the storage buffer and it crashes.

The problem is still there, but now the application works.

Thanks to all that had responded and tryed to help.
Hope this will be usefull to all.

Thanks!
Yours Truly
 [2002-04-23 06:32 UTC] fernando dot trindade at oni dot pt
Additional note:

The buffer that's used is the on the CLIENT side.
Not on the server as I stated above.

Again, Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 30 01:01:28 2024 UTC