1 08/22/83  Allocation Storage
 2 
 3 The Multics system uses several areas (in the PL/I sense) for storage
 4 of data by both system and user programs.  A certain class of problems
 5 can be avoided by specifying which area is to be used for allocations
 6 of a particular type.  In order to understand how to use the tools to
 7 help avoid this class of problems, the following table is given
 8 listing the various areas managed by the system and the type of
 9 allocations done in each.
10 
11      AREA                 ALLOCATIONS
12 
13      Combined Linkage     linkage sections
14                           reference names
15                           LOT/ISOT
16 
17 
18      Combined Static      static sections (separate static only)
19 
20      System Free          users of get_system_free_area_
21 
22      User Free            control tables for external variables
23                           pl1 allocations with no "in" clause
24                           pl1 controlled variables
25                           pl1 external variables without $ in the name
26                           fortran common blocks
27                           cobol data
28                           callers of get_user_free_area_
29 
30 These areas are found via pointers in the stack header.
31 
32 
33 Initially, all pointers point to the same extensible area--one or more
34 segments in the process_dir named [unique].area.linker.
35 
36 Hence, user allocations and system allocations are made in the same
37 area.  This is done to minimize paging and process directory segments.
38 However, if a user program has a bug such that it references beyond
39 the end of an allocated block (or references a block it has freed,
40 etc.), it is possible for the program to damage system data and, in
41 particular, the control data of the area manager.
42 
43 
44 The system data that can be damaged falls into four basic categories--
45 
46 1)   links and linkage sections in general
47 2)   static storage of system programs
48 3)   allocated storage of system programs
49 4)   area control info (stored in the area itself)
50 
51 If data in one of the first three classes is overwritten, fairly
52 random and unexpected behavior results; a new proc (or hangup) is the
53 only way out.  If the area control info is overwritten, the condition
54 "bad_area_format" is signaled the next time an allocation is
55 attempted.  In this case, the area_status command might be used to
56 determine which part of the area has been destroyed.
57 
58 
59 If it is suspected that the area has been damaged due to user program
60 bugs, the set_user_storage command can be used to force user data to
61 be allocated in a different area thereby probably protecting system
62 data so that the normal debugging tools could be used.  The easiest
63 way to do this is probably in the start_up.ec by first creating an
64 area (with the create_area command) and then telling the system to use
65 this area for user allocations (with the set_user_storage command).
66 This usually protects all system data from random user program bugs.
67 
68 Note that it is convenient to create the user area in a nonprocess
69 directory segment so that it can be examined in the case of a process
70 termination.