{5} Accepted, Active Tickets by Owner (Full Description) (2 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
Eric Swenson (1 match)
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #272 | Crank runs give warnings about missing PDTs | Administration | issue | 5 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When you run the crank on a newly-coldbooted system, you get the following warnings: pdt_copy: Entry not found. Operator.pdt pdt_copy: Entry not found. HFED.pdt pdt_copy: Entry not found. Terminals.pdt compute_bill: Entry not found. Operator.pdt compute_bill: Entry not found. HFED.pdt compute_bill: Entry not found. Terminals.pdt update_pdts_from_reqfile: Entry not found. Operator.pdt update_pdts_from_reqfile: Entry not found. HFED.pdt update_pdts_from_reqfile: Entry not found. Terminals.pdt These are not fatal, and probably even reasonable. It probably makes sense to NOT install the Operator, HFED, and Terminals projects automatically. However, if we agree that this is true, it might be nice to update the crank to not provide these warnings (or not). This ticket is here so that we can decide. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Gary Dixon (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #424 | cv_ptr_$terminate can cause termination of segment being initiated by segno | Standard Library | MR12.9 | defect | 10 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If a program like area_status is invoked to display status information about the system free area, it can unintentionally terminate that segment by calling cv_ptr_$terminate as documented. Documentation says callers of cv_ptr_ should call cv_ptr_$terminate to remove a null reference name from count associated with the segment. But if such callers gave a segment number as input to cv_ptr_, the new cv_ptr_ does not initiate that segment with a null reference name (since it is already known to the process). It just returns a pointer to the segment. When the caller subsequently calls cv_ptr_$terminate for an outer-ring segment, a reference name will be removed from the segment. If the segment's null reference counter drops to zero, the segment will be made unknown to the process. A worst-case example: call cv_ptr_ [call get_system_free_area_ -out -return] -out -code -out -- Return from: cv_ptr_ ------- code02 OK retValue 247|0 r 14:02 0.150 17 call cv_ptr_$terminate 247|0 Fatal error. Process has terminated. Improper access on user's linkage segment. New process created. This problem can occur more in a less-expected manner by invoking a command which calls cv_ptr_ with an input VIRTUAL_PTR string. area_status [call get_system_free_area_ -out -return]
Busy Free
Blocks 86 5
Words 66052 112
194932 words of virgin storage
in 1 components.
Zero on free in effect.
Fatal error. Process has terminated. Improper access on user's linkage segment.
New process created.
I think the old cv_ptr_ had this same problem. For callers of the new cv_ptr_$details entry point, the details returned to the caller along with the pointer indicate when cv_ptr_$terminate should not be called when the segment pointed to is: an inner-ring segment, or was already known to the process. But the cv_ptr_ interface has no way of knowing when it should or should not call cv_ptr_$terminate. I think the cv_ptr_ interface should always initiate an outer-ring segment with a null reference name, whether or not is was already known to the process. That way, the null reference name counter can be decremented without causing the segment to be made unknown to the process. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
