| 1 | | Test problem. |
| | 1 | The exec_com (version 2) program language includes a set of features which enable the program to establish an on-unit to handle one or more conditions that might occur while the program is executing. |
| | 2 | |
| | 3 | {{{ |
| | 4 | &on active_function_error &begin |
| | 5 | &set status_code &[status_code_name &condition_info_ptr] |
| | 6 | &print Condition &condition_name occurred to report event |
| | 7 | &print &" " at location &condition_info_ptr |
| | 8 | call cu_$cl |
| | 9 | &end |
| | 10 | ... |
| | 11 | }}} |
| | 12 | |
| | 13 | The &condition_info_ptr parameter is supposed to expand to a virtual pointer |
| | 14 | (<segment_number>|<offset>) locating a condition_info structure |
| | 15 | describing the condition being handled. This permits a command or |
| | 16 | active function to access added details about the event being handled |
| | 17 | by the current on-unit invocation. For example, the on-unit shown above |
| | 18 | sets the status_code variable to the name of the Multics status code |
| | 19 | being reported in a com_err_ or active_fnc_err_ subroutine call. |
| | 20 | |
| | 21 | However, the exec_com interpreter does not properly call the |
| | 22 | find_condition_info_ subroutine to fill-in elements of the |
| | 23 | condition_info structure before executing line of the on-unit. The |
| | 24 | &condition_info_ptr parameter does locate a data structure, but |
| | 25 | elements of that structure contain previous stack data because |
| | 26 | the structure was not properly initialized with details from the |
| | 27 | reported event. |
| | 28 | |
| | 29 | Executing an exec_com program with the statements above currently |
| | 30 | generates a virtual_ptr value for the &condition_info_ptr that has |
| | 31 | a correct format for a pointer locator, but points to storage for a |
| | 32 | condition_info structure with bogus element contents. |
| | 33 | |
| | 34 | {{{ |
| | 35 | ec test_status |
| | 36 | Condition active_function_error occurred to report event |
| | 37 | at location 234|14716 |
| | 38 | |
| | 39 | r 16:54 0.192 7 level 2 |
| | 40 | |
| | 41 | ds 234|14716 -as condition_info -lg |
| | 42 | 014716 |
| | 43 | condition_info @ 234|14716 |
| | 44 | mc_ptr = 0(0),au [invalid] |
| | 45 | version = 0, |
| | 46 | condition_name = "" |
| | 47 | info_ptr = 6(0) [invalid] |
| | 48 | wc_ptr = 247|7034 [pd]>!BBBKbbxJZGjlPk.area.linker |
| | 49 | loc_ptr = 234|14562 [pd]>stack_4 |
| | 50 | flags @ 234|14740 |
| | 51 | OFF: crawlout |
| | 52 | user_loc_ptr = 234|14516 [pd]>stack_4 |
| | 53 | r 16:54 0.182 5 level 2 |
| | 54 | }}} |
| | 55 | |
| | 56 | The condition_name is blank, and most other data in the structure is |
| | 57 | invalid. This is especially true of condition_info.info_ptr which |
| | 58 | is supposed to locate the com_af_error_info structure created by |
| | 59 | active_fnc_err_ when it signals the active_function_error condition. |
| | 60 | |
| | 61 | The data at location 234|14716 is shown by the dump_segment command. |
