| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1446.1 | Known problem; fixed with OS support. | WTFN::SCALES | Despair is appropriate and inevitable. | Wed Dec 04 1996 18:26 | 32 |
| 1446.2 | | TAEC::BEROUD | Telecom Engineering - MCC maintenance- VBE - Dtn: 828-5244 | Thu Dec 05 1996 09:47 | 164 |
| 1446.3 | It works for me... | WTFN::SCALES | Despair is appropriate and inevitable. | Thu Dec 05 1996 21:18 | 29 |
| 1446.4 | | ZIMBRA::BERNARDO | Dave Bernardo, VMS Engineering | Thu Dec 05 1996 22:39 | 5 |
| 1446.5 | RE: -2 You are right, My IMAGE_MANAGEMENT execlet is older than yours... | TAEC::BEROUD | Telecom Engineering - MCC maintenance- VBE - Dtn: 828-5244 | Fri Dec 06 1996 08:07 | 32 |
| 1446.6 | VERY VERY WORRIED ! It works OK even with default condition handling on any thread under OpenVMS ALPHA G7.1 | TAEC::BEROUD | Telecom Engineering - MCC maintenance- VBE - Dtn: 828-5244 | Fri Dec 06 1996 14:16 | 129 |
| 1446.7 | The example without establishing my own condition handling under T7.1 | TAEC::BEROUD | Telecom Engineering - MCC maintenance- VBE - Dtn: 828-5244 | Fri Dec 06 1996 14:51 | 107 |
| 1446.8 | It still works for me on V7.0 | WTFN::SCALES | Despair is appropriate and inevitable. | Fri Dec 06 1996 16:02 | 55 |
| 1446.9 | | ZIMBRA::BERNARDO | Dave Bernardo, VMS Engineering | Fri Dec 06 1996 20:32 | 9 |
| 1446.10 | Entered this problem as IPMT case CFS.47297 Severity 1 to VMS | TAEC::BEROUD | Telecom Engineering - MCC maintenance- VBE - Dtn: 828-5244 | Mon Dec 09 1996 16:05 | 20 |
| 1446.11 | Status update | WTFN::SCALES | Despair is appropriate and inevitable. | Mon Jan 06 1997 18:20 | 14 |
| 1446.12 | could other lib$signals cause a similar problem | NABSCO::RUBENSTEIN | | Tue Apr 22 1997 17:44 | 45 |
| I have a situation where a piece of code uses lib$signal with two additional arguments intended for fao.
The code works as expected (the error message is sent out with all the arguments) on vax vms 6.x and v.7.1. it
also works properly on vax and alpha running vms7.1.
Its behavior changes when the same code is run on alpha vms 7.0. Here the message is sent out without the fao
arguments, and there is an additional message from cma stating some information was lost.
The image is linked on a alpha running vms 6.1 there are no code changes or conditional compiles related to the
different vms versions.
The lib$signal call is implemented as a calls; the fao arguments live in a separate psect for data.
Any Ideas about what is so different in vms7.0 running on an alpha versus 6.2 or 7.1 ?
.PSECT RWD,WRT,NOEXE,LONG
.
.
filename_d: .long 0 ; Empty descriptor to use for
.long 0 ; lookup
format_present_flag: .long 0 ; Flag to indicate presenct
; of /FORMAT qualifier.
arglist:
.long 0 ; number of args
.long 0 ; signal
.long 0 ; number of fao args
.address filename_d ; descriptor
.long 0 ; safety
.PSECT ROI,NOWRT,EXE,LONG
;
A_REST::
.if defined,alpha
.jsb_entry preserve=<r3,r4,r5,r6,r7>
.endc
.
.
.
pushal filename_d
pushl #1
pushl #SLS$_NOHISTREC
calls #3,g^lib$signal
|
| 1446.13 | It's fixed in V7.1, at last. | WTFN::SCALES | Despair is appropriate and inevitable. | Tue Apr 22 1997 21:57 | 28 |
| .12> Any Ideas about what is so different in vms7.0 running on an alpha versus
.12> 6.2 or 7.1 ?
Sure. What you're seeing on V7.0 in the initial thread is the behavior that has
always been exhibited by created threads prior to V7.1 -- that is, in Alpha V7.0
(and in VAX V7.1), we finally "fixed" the initial thread (via support from the
image activator) so that it's basically just like all of the other threads --
you see the context of the exception at the last point it was re-raised, and the
information gets lost/stripped at the re-raise.
From the perspective of this particular issue, that may not necessarily have
been a step forward. Nevertheless, in a number of other, overriding ways, it
was a definite improvement.
The unfortunate thing is, there is a TRY/CATCH block in the frame which calls
each thread's start routine (or main() for the initial thread), and prior to
V7.1 this guaranteed that the entire stack was unwound during exception
propagation. In V7.1, we "fixed" the TRY/CATCH block so that it's only
activated if the exception being raised is a DECthreads internal one. Thus, the
final context is the point at which the exception was raised, or the last place
it was reraised in application (or some other library) code.
So, if the thread has no TRY/CATCH blocks (other than the now special one in
base frame of the thread stack), a condition signalled with lib$signal or
lib$stop should come through intact, in any thread, as of V7.1.
Webb
|