github.com/DARA-Project/GoDist-Scheduler@v0.0.0-20201030134746-668de4acea0d/README.md (about) 1 # GoDist-Scheduler 2 ![scheduler](https://i.stack.imgur.com/bzDfr.png) 3 4 GoDist-Scheduler is a global scheduler for model checking distributed systems. The GoDist-Scheduler communicates to 5 insturmented version of the Golang runtime via shared memory. The insturmented runtime can be found 6 [here](https://github.com/DARA-Project/GoDist). 7 8 ## Getting Started 9 10 To install GoDist-Scheduler you must have a working installation of [Go](https://golang.org/doc/install). 11 Second [GoDist](https://github.com/DARA-Project/GoDist) (insturmented go runtime) must be installed to `/usr/bin/dgo` 12 in future releases this location with be configurable. 13 14 ### Environment Variables 15 16 Go packaging relies heavily on the GOPATH environment variable. Make sure that the GOPATH environment variable is set before moving on. 17 You can check if GOPATH is set by executing the following command: 18 19 ``` 20 > echo $GOPATH # Output should be the path to which GOPATH is set 21 ``` 22 23 The bin folder of the GOPATH folder must also be a part of the PATH variable. 24 You can append it to the PATH variable as follows: 25 26 ``` 27 > export PATH=$PATH:$GOPATH/bin 28 ``` 29 30 Ensure that the modified go runtime (dgo) is setup correctly 31 32 ``` 33 > which dgo # Output should be /usr/bin/dgo 34 ``` 35 36 Make sure that the binary `GoDist-Scheduler` is in your `$PATH`. You can find out by running: 37 38 ``` sh 39 which GoDist-Scheduler 40 ``` 41 42 If you cannot find it, link `$GOPATH/bin/GoPath-Scheduler` to a directory in your `$PATH`. If `GoPath-Scheduler` is not in `$GOPATH/bin` run `go install` and the executable should be on that file. 43 44 You will also need to have `dinv` cloned. You can get the [code here](https://github.com/ModelInference/dinv) and make sure to put it in `$GOPATH/src/bitbucket.org/bestchai/dinv`. 45 46 ## Running Dara 47 48 ### Configuration File 49 50 Running the concrete model checker requires the use of a configuration file. 51 52 NOTE: This is not the final version of the configuration file as it will be modified 53 to support complicated distributed systems that have their own specific build and run scripts as well 54 as include configurable options for exploration strategies and depth. 55 56 ``` 57 { 58 "exec" : { 59 "path" : "/path/to/examples/SimpleFileRead/file_read.go", 60 "size" : "400M", 61 "processes" : 1, 62 "sched" : "file_read.json", 63 "loglevel" : "INFO", 64 "property_file" : "/path/to/property/file.prop" 65 "build" : { 66 "build_path" : "../examples/ServerClient/build.sh", 67 "run_path" : "run.sh" 68 } 69 }, 70 "instr" : { 71 "dir" : "", 72 "file" : "../examples/SimpleInstrument/file_read.go" 73 "out_dir" : "", 74 "out_file" : "../examples/SimpleInstrument/file_read_instrumented.go", 75 "blocks_file" : "../examples/SimpleInstrument/blocks" 76 } 77 } 78 ``` 79 80 The exec block in the configuration file refers to the execution options of the system. 81 The details of every field for all the execution options is presented as follows: 82 83 + `path` : The full path to the file which contains the main function the system 84 + `size` : The size of the shared memory to be used by the global-scheduler and the local go runtimes. 85 + `processes` : The number of processes that need to be launched that will execute the main function 86 + `sched` : The name of the schedule file that will be used to write to/read from for doing record/replay or exploration. 87 + `loglevel` : The level of the logging that needs to be printed out to console. Supported levels are : DEBUG, INFO, WARN, FATAL 88 + `property_file` : The path to the property file that contains the properties! 89 + `build`: This is to allow for complicated build and run scripts. 90 + `build_path`: Path to build script 91 + `run_path`: Path to run script 92 93 The instr block in the configuration file refers to the instrumentation options of the system. 94 Currently either a single file can be instrumented or the whole directory can be instrumented. 95 The details of each field are as follows: 96 97 + `dir` : The full path to the directory to be instrumented 98 + `file` : The full path to the file to be instrumented 99 + `out_dir` : The full path to the output directory where the instrumented source code will be written. If not provided then all go files in the directory are modified. 100 + `out_file` : The full path the output file where the instrumend file will be written. If not provided then the input file will be modified. 101 + `blocks_file`: The full path to the filename where list of all blockIDs will be written. This is a required argument. This file is used by cov_report auxiliary tool to generate a coverage report. 102 103 ### Property File 104 105 A property file should only have function definitions 106 and comment for the function. The definition corresponds 107 to the property to be checked. The comment provides 108 the meta information: Property name and full qualified 109 path of each variable in the source package. The full 110 qualified path is used for data collection 111 112 Caveat: The variables used in the property must start 113 with an uppercase letter 114 115 Example of a property: 116 117 ``` 118 //Equality 119 //main.a 120 //main.b 121 func equality(A int, B int) { 122 return A == B 123 } 124 ``` 125 126 For a more concrete example, please look at this [example](examples/SharedIntegerNoLocksProperty). 127 128 #### Reporting Variable Values 129 130 Notice that for properties to be checked, Dara needs to know information about values of the variables needed by the property. 131 This requires the user to appropriately instrument the code to report values of the variables. 132 The function call used to report values of variables for the property above is as follows: 133 134 ``` 135 runtime.DaraLog("LogID", "main.a, main.b", a, b) 136 ``` 137 Here the first argument is a LogID that is used to identify the unique location where this function call is made from. 138 The second argument is a string containing the names of the variables whose values are being reported 139 as part of the function call. The names of the variables are joined using a comma. The values of the variables 140 follow as the final arguments. As you might have guessed, runtime.DaraLog accepts variadic number of arguments to allow 141 for any number of varibles to be reported. 142 143 NOTE: The names of the variables do have to match the names of the variables used in property file 144 but they don't need to match the actual variable names in the source code. We recommend the use 145 of fully qualified variable names to avoid any potential naming conflicts. 146 147 #### Reporting Values for Channels 148 149 Channels are specific to Go and developers might want to write properties that check the state of the channel. 150 To support such properties, Dara provides two functions through the runtime package 151 which report the number of sends and number of deliveries that have occurred on that channel. 152 153 + runtime.NumSendings(chan interface{}) int: Returns the number of sends that has happened on channel chan 154 + runtime.NumDeliveries(chan interface{}) int: Returns the number of deliveries that has happened on channel chan 155 156 ### Record 157 158 To record a schedule, use the overlord program provided as part of the GoDist-Scheduler. 159 The steps for recording the schedule using the overlord is as follows: 160 161 ``` 162 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/overlord 163 > go run overlord.go -mode=record -optFile=system_config.json 164 ``` 165 166 ### Replay 167 168 To replay a schedule, use the overlord program provided as part of the GoDist-Scheduler. 169 The steps for replaying the schedule using the overlord is as follows: 170 171 ``` 172 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/overlord 173 > go run overlord.go -mode=replay -optFile=system_config.json 174 ``` 175 176 ### Explorer (experimental) 177 178 To explore different interleavings for a system, use the overlord program provided as part of the GoDist-Scheduler. 179 The steps for exploration using the overlord is as follows: 180 181 ``` 182 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/overlord 183 > go run overlord.go -mode=explore -optFile=system_config.json 184 ``` 185 186 ### Instrument 187 188 To instrument a system so that it reports coverage information, use the overlord program as follows: 189 190 ``` 191 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/overlord 192 > go run overlord.go -mode=instrument -optFile=system_config.json 193 ``` 194 195 ## Auxiliary Tools 196 197 Understanding the bug traces can be hard. Thus, to aid in the understanding of the debug traces, 198 we make use of existing tools like ShiViz and provide some of our own tools. 199 200 ### Schedule Info Tool 201 202 The Schedule Info tool prints out meta information about a schedule. Currently, it prints 203 out the number of events in the schedule as well as breakdown of events by the type of the event. 204 205 To run the info tool, execute the following steps 206 207 ``` 208 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/tools 209 > dgo run schedule_info.go <schedule_filename> 210 ``` 211 212 Sample output from running the schedule info is shown below 213 214 ![info](img/info.png?raw=true) 215 216 ### ShiViz Converter Tool 217 218 The ShiViz converter tool converts a recorded or replayed schedule into a ShiViz-compatible 219 look which can be used to visualize the bug trace using the [online Shiviz tool](https://bestchai.bitbucket.io/shiviz/). 220 221 To run the converter tool, execute the following steps 222 223 ``` 224 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/tools 225 > dgo run shiviz_converter.go <schedule_filename> <shiviz_filename> 226 ``` 227 228 A snapshot of the ShiViz visualization of the generated log from the recorded schedule 229 is shown below: 230 231 ![shiviz](img/shiviz.png?raw=true) 232 233 ### Coverage Report Tool 234 235 The Coverage Report tool produces a coverage report indicating which blocks in the source code were 236 covered and which blocks were not uncovered. 237 238 To run the report tool, execute the following steps 239 240 ``` 241 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/tools 242 > dgo run cov_report.go <schedule_filename> <blocks_filename> 243 ``` 244 245 Sample output is as follows: 246 247 ``` 248 Total # of blocks in source code: 6 249 Total # of blocks covered: 3 250 Total # of blocks uncovered: 3 251 Covered Block Frequency 252 ../examples/SimpleInstrument/file_read.go:10:12 1 253 ../examples/SimpleInstrument/file_read.go:12:14 1 254 ../examples/SimpleInstrument/file_read.go:24:26 1 255 Uncovered Blocks: 256 ../examples/SimpleInstrument/file_read.go:16:18 257 ../examples/SimpleInstrument/file_read.go:21:21 258 ../examples/SimpleInstrument/file_read.go:18:20 259 ``` 260 261 262 ### Variable Info Tool 263 264 Specifying properties requies using the full name scope name of a variable. 265 We wrote a tool that helps you extract all the user-defined variables 266 in your code. 267 268 ``` 269 > cd $GOPATH/src/github.com/DARA-Project/GoDist-Scheduler/tools 270 > go run variable_info.go <path/to/binary> 271 ```