| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4945.1 | | DUCATI::LASTOVICA | Is it possible to be totally partial? | Wed Jan 22 1997 11:06 | 12 |
| 4945.2 | | AVMSV1::EKREISLE | Erich Kreisler | Wed Jan 22 1997 11:31 | 8 |
| 4945.3 | /virtual | AVMSV1::GEDER | Gottfried Eder | Thu Jan 23 1997 03:26 | 5 |
| 4945.4 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Thu Jan 23 1997 10:13 | 15 |
| 4945.5 | | AVMSV1::EKREISLE | Erich Kreisler | Mon Feb 10 1997 12:49 | 3 |
| Is not reproducible, but entered bug 449000.
erich
|
| 4945.6 | Same on show index | chsr38.ch.oracle.com::ROHR | The Packers did it! | Mon Feb 24 1997 09:06 | 60 |
| For the record: I had this one on a show index VMS 6.2 AXP MV7.0.
Same module, but different stack. When I quit SQL and reentered I could
not reproduce.
What is SQL$61 doing in the stack?
Saved PC = 010DE7BC : STD$DUMP_ALPHA_VMS_STACK + 000000DC
Saved PC = 010BBE6C : KOD$BUGCHECK_DUMP + 00000D9C
Saved PC = 00D86344 : RDMS$$REQUEST_HNDLR + 00000284
Saved PC = 80007164 : symbol not found
Saved PC = 83BD42BC : symbol not found
***** Exception at 00F17C94 : DIOFETCH$FETCH_SNAP_SEG + 000005A4
Saved PC = 00F18290 : DIOFETCH$FETCH_VISIBLE_SEG + 00000540
Saved PC = 00F1901C : DIOFETCH$FETCH_ONE_LINE + 00000B7C
Saved PC = 00F19900 : DIOFETCH$SCAN_ONE_PAGE + 00000298
Saved PC = 00F19C10 : DIO$FETCH_AREA + 000001A8
Saved PC = 00D440F0 : RDMS$$EXE_NEXT + 00001ED8
Saved PC = 00D42760 : RDMS$$EXE_NEXT + 00000548
Saved PC = 00D42598 : RDMS$$EXE_NEXT + 00000380
Saved PC = 00D4598C : RDMS$$EXE_OPEN + 0000107C
Saved PC = 00D44DCC : RDMS$$EXE_OPEN + 000004BC
Saved PC = 00D449FC : RDMS$$EXE_OPEN + 000000EC
Saved PC = 00D42608 : RDMS$$EXE_NEXT + 000003F0
Saved PC = 00D4598C : RDMS$$EXE_OPEN + 0000107C
Saved PC = 00D4671C : RDMS$$EXE_OPEN + 00001E0C
Saved PC = 014D81A0 : symbol not found
Saved PC = 00D59D90 : RDMS$TOP_START_AND_SEND + 00000700
Saved PC = 011E60BC : LIB$$CVT_MULH + 0000C1B0
Saved PC = 00F57940 : KOD$SETSTK_AND_CONTINUE + 00000140
Saved PC = 00F576BC : KODSTREAM$DO_THREAD + 000000BC
Saved PC = 00F57530 : KOD$STREAM_REQUEST + 00000298
Saved PC = 00F58A44 : KOD$STALLAST + 00000084
Saved PC = 00F58AA8 : KOD$STALLAST_RMS + 00000048
Saved PC = 800805A4 : symbol not found
Saved PC = 80081DAC : symbol not found
Saved PC = 009FA9C8 : Image RDMSHR70 + 0004A9C8
Saved PC = 009F9B0C : Image RDMSHR70 + 00049B0C
Saved PC = 007D2920 : Image RDB$SHARE70 + 000D0920
Saved PC = 007A3D8C : Image RDB$SHARE70 + 000A1D8C
Saved PC = 007CCC48 : Image RDB$SHARE70 + 000CAC48
Saved PC = 007C36EC : Image RDB$SHARE70 + 000C16EC
Saved PC = 007C2F78 : Image RDB$SHARE70 + 000C0F78
Saved PC = 007C2EB8 : Image RDB$SHARE70 + 000C0EB8
Saved PC = 007BBB6C : Image RDB$SHARE70 + 000B9B6C
Saved PC = 007A3C44 : Image RDB$SHARE70 + 000A1C44
Saved PC = 007323A4 : Image RDB$SHARE70 + 000303A4
Saved PC = 0064BD10 : Image RDBSHR + 0006DD10
Saved PC = 0063FE40 : Image RDBSHR + 00061E40
Saved PC = 00602D40 : Image RDBSHR + 00024D40
Saved PC = 000E98B4 : Image SQL$61 + 000D98B4
Saved PC = 000EEB40 : Image SQL$61 + 000DEB40
Saved PC = 001F7240 : Image SQL$61 + 001E7240
Saved PC = 001F2FF0 : Image SQL$61 + 001E2FF0
Saved PC = 001D08DC : Image SQL$61 + 001C08DC
Saved PC = 00163B24 : Image SQL$61 + 00153B24
Saved PC = 001634FC : Image SQL$61 + 001534FC
Saved PC = 0015866C : Image SQL$61 + 0014866C
Saved PC = 7EF36160 : symbol not found
|
| 4945.7 | | HOTRDB::LASTOVICA | Is it possible to be totally partial? | Mon Feb 24 1997 09:17 | 7 |
| that is really curious. If you get a chance, on the system where this
occured, run SQL again (the same way that you did before) and, from
another session, go into SDA and for the process running SQL, do a SHOW
PROC/IMAGE and a SHOW PROC/CHAN.
The 'Image SQL$61 +' lines are symbolized using some OpenVMS data
structures so I can not imagine where it would goof up.
|
| 4945.8 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Mon Feb 24 1997 09:58 | 5 |
| > What is SQL$61 doing in the stack?
The dumper will display the image name for every image with a return PC
on the stack. In your case you are running interactive SQL, so PCs
from the image get on the stack and thus are dumped.
|
| 4945.9 | SQL 6.1-1 and Rdb 7.0 | chsr38.ch.oracle.com::ROHR | The Packers did it! | Mon Feb 24 1997 10:10 | 16 |
| Don't know how this happened, but I was running SQL 6.1-1 and Rdb V7 (I
was attached to a V7 database). That's how SQL$61 got on the stack.
But I doubt it is the cause of the bugcheck dump, when I reentered
under the same conditions I could do a show index.
SQL> sh version
Current version of SQL is: DEC SQL V6.1-1
SQL> att 'f db$70:mfp70';
SQL> exit
Rohr> shover
Current PROCESS Oracle Rdb environment is version V7.0-0 (MULTIVERSION)
Current PROCESS SQL environment is version V7.0-0 (MULTIVERSION)
Current PROCESS Rdb/Dispatch environment is version V7.0-0 (MULTIVERSION)
/Regina
|
| 4945.10 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Mon Feb 24 1997 11:28 | 1 |
| Try doing a SHOW LOGICAL SQL$.
|
| 4945.11 | | AVMSV1::EKREISLE | Erich Kreisler | Thu Mar 13 1997 12:46 | 13 |
| The customer had this problem again, but this time he did a load. The load just
went into a loop consuming 100% CPU and after he stopped the process and then
did a show table (after recovery finished) he got a bugcheckdump with the same
exception.
Also he now has ABM errors reported like
ABMBITERR
BADABMPAG
Told him to repair the ABMs and then do again a verify.
Ciao,
erich
|
| 4945.12 | same bug during a show tables | CHSR36::LCONS | | Wed Mar 19 1997 11:04 | 3 |
| Rdb7, Vms7.1
Another ct reports this error.
I've asked for a verify of the db
|