Hello,
I have an problem with an application build by our company. The application is
build in an USOFT environment (usoft is an development environment).
The usoft application (Win NT) core dumps sometimes (the problem is
reproduceble). The client environment is 8163 NT and the database is on IBM
NUMA-Q sequent dynix/ptx 8161. Usoft tells us that the crash is because a bug
in oracle. The oracle bug number is 1530731 (please see below).
USOFT don't implement the workaround "Do no mix fetches with and without
INDICATOR variables." because it is an oracle problem.
At the moment there is NO FIX for this bug. And even oracle support Holland
can't say when there is a fix for this bug in oracle 816 on NT.
I am interested if there are more people have trouble with this bug?
Please tell me your experience!
Do you have any information when oracle is fixing this bug?
The bug is also in client 817!
I appreciate to get any information.
Greeting from Holland,
Bert.
Bug No. 1530731
Filed 06-DEC-2000 Updated 05-MAR-2001
Product Oracle Server - Enterprise Edition V7 Product Version 8.1.6
Platform Intel Windows NT Platform Version 8.1.6
RDBMS Version 8.1.6 Affects Platforms Generic
Priority Minimal Loss of Service Status Code Bug (Response/Resolution)
Base Bug N/A Fixed in Product Version No Data
Problem statement:
PROC APPLICATION CORE DUMPS AFTER DOING FETCHES WITH AND WITHOUT INDICATOR VAR.
-
- 12/06/00 02:12 am ***
PROBLEM:
.
- Clear description of the problem encountered:
PROC application core dumps on second FETCH if first FETCH is done
with indicator variables and second FETCH executed without Indicator
variables using same CURSOR.
- Pertinent configuration information (MTS/OPS/distributed/etc)
N/A
- Indication of the frequency and predictability of the problem
every time testcase runs
- Sequence of events leading to the problem
Compile testcase
- Technical impact on the customer. Include persistent after effects.
- has a huge project doing FETCHES with Indicator variables and
without against same prepared CURSOR. C. needs check its complete
code to avoid such a specific FETCH scenario.
DIAGNOSTIC ANALYSIS:
Reading Chapter 6 page 14 PROC 8.1.5 manual we are able to fetch into
different host variables.
for (;;)
{
EXEC SQL FETCH emp_cursor INTO :emp_name1, :salary1;
EXEC SQL FETCH emp_cursor INTO :emp_name2, :salary2;
EXEC SQL FETCH emp_cursor INTO :emp_name3, :salary3;
} ...
We should also be able to detect whether c. uses
INDICATOR/NO_INDICATOR variables for each FETCH operation.
On any case we should document that behaviour.
( checked docu but could locate any discription that this type
type of fetch operation is not supported ).
Core dump are not easy for debugging and if second FETCH occurs in a
very seldom called routine these errors could lead to wasting time
for customers and support to locate these errors.
Code:
EXEC SQL OPEN c1;
EXEC SQL FETCH c1 INTO :num :iVar;
EXEC SQL FETCH c1 INTO :num;
---> Core dump
=========================
.
WORKAROUND:
Do no mix fetches with and without INDICATOR variables.
.
RELATED BUGS:
None.
.
REPRODUCIBILITY:
.
- State if the problem is reproducible; indicate where and predictability
run testcase
- List the versions in which the problem has reproduced
8.1.7 Sun Solaris 2.6
8.1.6 Sun Solaris 2.6
8.1.6 HP-UX 11.0
8.1.6 IRIX
8.1.6 NT
- List any versions in which the problem has not reproduced
.
TESTCASE:
File: m.pc
Compile and Link: make -f demo_proc.mk build EXE=m OBJS=m.o
.
.
STACK TRACE:
Sun Solaris HP-UX
- ----------------
_memcpy() ttcfSetIndRc ()
ttcfour() ttcfour()
ttcdrv() ttcdrv()
nioqwa() nioqwa(
..... ......
.
SUPPORTING INFORMATION:
.
24 HOUR CONTACT INFORMATION FOR P1 BUGS:
N/A
.
DIAL-IN INFORMATION:
N/A
.
IMPACT DATE:
.
- 12/06/00 02:13 am *** (CHG: Sta->16)
- 12/06/00 02:38 am ***
Testcase: /bug/bug1530731/m.pc
- 12/07/00 01:52 am ***
- 12/07/00 03:01 am *** (CHG: Sta->11 Asg->NEW OWNER)
- 12/07/00 03:01 am ***
Testing with an equivalent OCI program (oci.c on ess30) and the behaviour is
the same, ie it core dumps here when an indicator is used on the first fetch
but not the second. It also core dumps even if you reexecute the statement
after the redefine call. So the two failing cases are:
.
- Define host var and indicator
Execute and fetch 1 row
Define (second) host var, no indicator
Fetch 1 row - dumps
.
- Define host var and indicator
Execute and fetch 1 row
Define (second) host var, no indicator
Execute and fetch 1 row - dumps
.
The oci testcase also only reproduces from 8.1.6 (ie works in 8.0.6, 8.1.5,
fails 8.1.6, 8.1.7). To build use the demo makefile:
make -f demo_rdbms.mk EXE=oci OBJS=oci.o build
.
Switching component to OCI.
*** 12/07/00 04:39 am *** (CHG: Asg->NEW OWNER)
*** 12/07/00 04:39 am ***
*** 01/09/01 10:14 am *** (CHG: Asg->NEW OWNER)
*** 02/23/01 06:41 am ***
The problem is not confined to the indicator variable; the same happens if you
pass an rlenp (returned length) or rcodep (column level return code) parameter
the first time but not the second.
*** 03/05/01 06:29 am ***
.
Received on Thu Mar 08 2001 - 15:57:19 CST
