__group__	ticket	summary	component	milestone	type	created	_changetime	_description	_reporter
eswenson	272	Crank runs give warnings about missing PDTs	Administration		issue	2021-12-24T17:25:53Z	2026-09-15T17:50:51Z	"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. "	Eric Swenson
gdixon	424	cv_ptr_$terminate can cause termination of segment being initiated by segno	Standard Library	MR12.9	defect	2026-10-10T21:19:14Z	2026-10-10T21:20:58Z	"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.
"	Gary Dixon