<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Implement a Linux backend for the ProcessMemoryProvider plugin.
### Implementation description
<!-- Explain what you did to correct the problem -->
Most of the provider code is the same between Windows and Linux. The
primary differences are:
- enumerate PIDs in `/proc/` to get the process list
- use `/proc/<PID>/cmdline` as the process name
- parse `/proc/<PID>/maps` to get the module list
- reading/writing from memory is done using
`process_vm_readv`/`process_vm_writev`
NOTE: `sudo setcap CAP_SYS_PTRACE=+eip build/imhex` must be run to give
the binary permission to read another process' memory. Running as root
user should also work but I would not recommend it.
### Additional things
The existing translations keys no longer match since I moved the plugin
from `windows` to `builtin`.
I'm not well versed in C++ so I attempted to keep my changes rather
simple. Feedback is very welcome.
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
As discussed (many times) on Discord, does the same as the new favorite
tag, but instead allows you to add multiple groups.
Initially, this would cause some insane issues with draw/reset
(apparantly) fighting eachother in the pattern drawer. After a lot of
trial and error, I decided to rewrite the flow that is responsible for
calling reset. Now evaluating patterns is the one to decide when the
reset happens, not the core "game"-loop.
To make sure that draw and reset can never happen at the same time, the
mutex originally used for the favorites has been repurposed. Due to the
restructuring, the mutex in the favorite-task is no longer needed, as
that will only ever kick-off after reset is called and if there are
actually patterns, which can never line up to be accessed on different
threads at the same time.
Last but not least, I noticed that hard crashes could result in your
config file getting overridden. I added a check to prevent that.
Last I issue I can see is that if you use an excessive amount of
favorites/groups, a crash can still happen, but it only happens when you
close the program (occasionally, but unpredictable). Before, this would
happen if you ran the evaluation a second time. I boiled the cause of
the crash down to these lines of code in evaluator.cpp >
patternDestroyed:
```cpp
if (pattern->isPatternLocal()) {
if (auto it = this->m_patternLocalStorage.find(pattern->getHeapAddress()); it != this->m_patternLocalStorage.end()) {
auto &[key, data] = *it;
data.referenceCount--;
if (data.referenceCount == 0)
this->m_patternLocalStorage.erase(it);
} else if (!this->m_evaluated) {
err::E0001.throwError(fmt::format("Double free of variable named '{}'.", pattern->getVariableName()));
}
}
```
Specifically, trying to access the `*it` is the reason for the crash
(this was also the cause of the crashes before my fixes, but then during
evaluation).
I'm suspecting the root cause is somewhere in the `.clone` methods of
the patterns. I'd say that for now a crash when closing the program is
more acceptable than during evaluation (which can even happen if you use
favorites).
### Problem description
Currently, the providers use the method `isSavable()` to determine both
if they can use "Save" or "Save as".
This behaviour is problematic because some providers may need to be
saveable but not saveable as: for example the view provider. The
original provider may not allow to be saved.
### Implementation description
I separate these two behaviour by creating another function:
`isDumpable()`, that return true by default but can be overridden by the
provider to return false, if the provider should not be dumped in any
way.
### Additional things
While I was at it, I also marked "export" operations as needing the
"dumpable" flag. That way, we can't accidentally export the whole
address space of a process as base64.
I also added documentation for these some functions in Provider
In order to do this I add to make some other additions :
- Add a warning popup (TODO, maybe add some icons to differentiate
error/warning popups in a future PR ?)
- create showError() and showWarning() functions, as helpers to show a
message both to the logs and as a popup
