- Add caching to symbol table-driven module disassembly on Linux.
- Add configurable regex-based filtering for coverage collection, by module and module-scoped symbol name.
Block coverage recording can be manually tested using the `block_coverage` example in the `coverage` crate. See `./block_coverage -h` for expected args.
The filter file is optional. The file format is JSON like this:
```json
{
"modules": {
"allow": [
"<module-path-regex-1>",
"<module-path-regex-2>",
]
},
"symbols": {
"<module-path-regex-1>": {
"allow": [
"<symbol-name-regex-1>",
"<symbol-name-regex-2>",
]
},
"<module-path-regex-2>": {
"deny": [
"<symbol-name-regex-3>",
"<symbol-name-regex-4>",
]
}
}
}
```
Closes#285.
In debugging the connection retry issues, I dug into this more.
Apparently, some of hyper's connection errors are not mapped to std::io::Error, rendering the existing downcast impl ineffective.
As such, this PR makes the following updates:
1. Any request that fails for what `reqwest` calls a `connection` error is considered transient.
2. Updates the retry notify code to use our `warn` macro such that the events show up in application insights.
3. Updates the unit test to demonstrate that failures by trying to connect to `http://localhost:81/`, which shouldn't be listening on any system.
4. Adds a simple unit test to verify with send_retry_default, connections to https://www.microsoft.com work
Fixes#263
* Documents `crashes_account` and `crashes_container`
* Adds `reports_dir` and support for `unique_reports`, `reports`, and `no_repro` containers to the generic analysis task
* Adds `microsoft_telemetry_key` and `instance_telemetry_key` to generic supervisor, generator, and analysis tasks
In the supervisor agent, incrementally read from the running worker agent's redirected stderr and stdout, instead of waiting until it exits.
The worker agent's stderr and stdout are piped to the supervisor when tasks are run. The supervisor's `WorkerRunner` does _not_ use `wait_with_output()`, which handles this (at the cost of blocking). Instead, it makes repeated calls to to `try_wait()` on timer-based state transitions, and does not try to read the pipes until the worker exits. But when one of the child's pipes is full, the child can block forever waiting on a `write(2)`, such as in a `log` facade implementation.
This bug has not been caught because we control the child worker agent, and until recently, it mostly only wrote to these streams using `env_logger` at its default log level. But recent work: (1) set more-verbose `INFO` level default logging, (2) logged stderr/stdout lines of child processes of _the worker_, and (3) some user targets logged very verbosely for debugging. This surfaced the underlying issue.
* renames `telemetry_key` to `microsoft_telemetry_key`
* renames `instrumentation_key` to `instance_telemetry_key`
* renames `can_share` to `can_share_with_microsoft`
* renames the `applicationinsights-rs` instances to `internal` and `microsoft` respective of the keys used during construction.
This clarifies the underlying use of Application Insights keys and uses struct tuple to ensure the keys are used correctly via rust's type checker.
When users try to create a container immediately after deleting it, Azure will fail saying the deletion is in-progress.
catching ResourceExistsError during create handles this error.
As is, when multiple tasks are running on a single node, if any one of them stops, the node gets reimaged.
This changes the behavior such that when a node with multiple tasks has one task stop, the other tasks will continue.
