set_acl crashes initializer
M-> sa >ldd>MR12.5> rew Anthony.SysAdmin
1115 as act_ctl_: Automatic update: users = 2, pf=1, vcpu=0.823, rt=1.015
1115.0 attempt to terminate initializer process
1115.0 Multics not in operation; control process: Initializer.SysDaemon.z.
bce (crash) 1115.0:
azm: why
Inconsistency found in Dump Associative Memories.
Bootload cpu is a
Syserr messages from log partition:
Syserr message:
attempt to terminate initializer process
stack frame at 230|30000
called by 33|143 bound_error_active_1$terminate_proc|143
at stack frame 230|4140
Setting frame ptr (prfr) to 230|4140
FIM FRAME found at 230|3400
Machine Conditions at 230|3460:
Access Violation Fault (51), Out of Segment Bounds
PR6 (sp) - 230|3060 >sl1>stack_0.012|3060
By: 40|11230 bound_library_1_$signal_|1512
Ref: 230|200262 >sl1>stack_0.012|200262
Setting temporary pointers from machine conditions at 230|3460

Is it the rew? Nope; crashes with rw as well.

sa rew Anthony.SysEng works.

Okay, lets rebuild sve.rpv.dsk, adding the ring 2 login stuff to SysEng.

And load the MR12.5 tapes; reboot and salvage…. Curious if the problem lies in the Retreive creating corrupt segments and directories….

Salvaging >documentation.
Salvager reported
04  Corrected dtem for directory MR12.5
04  Corrected dtd for directory MR12.5
Salvaging >library_dir_dir.
Salvager reported
04  Corrected dtem for directory crossref
04  Corrected dtd for directory crossref

This implies that a emulator bug is causing the reload process to create broken segments and directories, which are causing problems later.

The set_acl still crashes the system, tho.

The dtem is date-time entry modified; dtd is date-time dumped; the salvager messages are red herrings.

The set_acl command is in ./library_dir_dir/system_library_standard/source/bound_access_commands_.s.archive/acl_commands_.pl1

The relevant code appears to be:

                    call hcs_$replace_acl (dname, ename, other_acl_ptr, acl_count, no_sysdaemon_sw, code);
replace_acl: entry (dname, ename, aptr, acount, dbit, code);
          else if esw = 2 then call asd_$replace_sall (dname, ename, aptr, acount, dbit, code);

I have an RPV with the tape images loaded: sve.rpv.dsk.MR12.5_tapes_loaded; copy it to sve.rpv.dsk.

../../../0fnp/src/dps8/dps8 start_sve.ini 

l Anthony.SysEng
ac x >ldd>sl1>s>bound_file_system.s asd_.pl1
; edit

call syserr (0, "start_proc");
          caller_level = level$get ();

pl1 asd_
; ignore undeclared syserr error...
cp >ldd>sl1>o>bound_file_system.archive
ac r bound_file_system asd_
bind bound_file_system
copy >ldd>sl1>info>hardcore.(search header) cac.=
i >user_dir_dir>SysEng>Anthony

On the console:

cwd >user_dir_dir>SysEng>Anthony
generate_mst cac trace -dr


M-> generate_mst cac trace -dr

Mounting tape trace for writing
1511.5  RCP: Attached tapa_01 for Initializer.SysDaemon.z
1511.5  RCP: Note (tapa_01) - trace,den=800
1511.5  RCP: Mount Reel trace with ring on tapa_01 for Initializer.SysDaemon.z

DBG(19811534748)> TAPE ERR: Set file permit?
Mounted Multics volume "trace" (recorded at 800 BPI), on device tapa_01
begin generation
generate_mst: Some directory in path specified does not exist. Invalid pathname 
\cin path list.
Last segment name encountered in header was bootload_tape_label
current line is 
boot_program:       bootload_tape_label;          end;

tape errors = 0
r 15:11 0.879 32



ls >user_dir_dir>SysEng>Anthony
ls >exl>net>h>chgs>e
list: Some directory in path specified does not exist. >exl>net>h>chgs
ls >exl

Where did that come form (or go to)?

Take the >exl line out of

Well, it looks like I finally found a place where I can't do a syserr call….

Lets try syserr (5,….)

Okay, that works, but is less useful.

start_proc is called many times; but I should be able to use azm to get the last of them. Let us try. "psl -syserr" shows

15:36:18 1000570  4 RCP: Unassigned tapa_00 from Utility.SysDaemon.z
15:36:45 1000571  5 start_proc
15:36:45 1000572  5 ==
15:36:45 1000573  5 ==
15:36:45 1000574  5 ==
15:36:45 1000575  5 ==

Do the set_acl…

yep, crashes. Reboot, azm…

Wierd. azm prints the system log backwards. Kinda confusing until you figure that out…

15:41:40 1000576  5 start_pr\000\000
15:36:45 1000575  5 start_proc
15:36:45 1000574  5 ==
15:36:45 1000573  5 ==
15:36:45 1000572  5 ==
15:36:45 1000571  5 ==

So it looks like start_proc does get called, and it goes pear-shaped pretty quick after that….

Fixed in alpha-2.0-RC3

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License