* Fix memory leaks in debug path
* Fix memory leaks in mach and mdmp format
* Update the fix for mach
* Add support for aarch64 tcache parsing
* Test case fix
* Comment update
---------
Co-authored-by: Giridhar Prasath R <giridh1337@gmail.com>
- All `ht_*_new0()` are removed
- `freefn` field of HT options was renamed to `finiKV`
- `finiKV_user` fields was added to HT options
- Added `ht_*_new_opt_size` API
- `HtSP` and `HtUP` are created with `ValueFree` callback that allows to reduce extra LOC and prevent bugs
- `SetP` replaced with `SetS` (based on `HtSP`)
- `rz_th_ht_*_new0()` and `rz_th_ht_*_new_opt()` are replaced with `rz_th_ht_*_new(HtXX *)`
Some more APIs were incorrectly checked for with __POWERPC__, even
though they have nothing to do with the architecture, but were only
introduced in Mac OS X 10.6.
- Add tcache heap heuristics
- Fetch glibc version from libc
- Add unit testcases for glibc version
Co-authored-by: Giridhar Prasath R <giridh1337@gmail.com>
If a function calls 'rz_cons_break_push()' but never calls 'rz_cons_break_pop()' before return,
the stack count of 'RzConsContext->break_stack' contains too many elements (each time one too much).
This in turn will lead to not resetting 'RzConsContext->breaked' flag.
Because the flag is only set to false, if 'rz_stack_is_empty(context->break_stack) == true'
(in 'rz_cons_context_break_push()').
This wasn't a problem so far, because 'RzConsContext->breaked' is simply never set to true
(exceptions are some timeout cases as far as I can see).
Also these cases when 'rz_cons_break_pop()' was forgetten to be called, were edge error cases.
So not often hit.
But if Rizin is usd by Cutter 'RzConsContext->breaked' is set to 'true',
if an `AnalysisTask` interrupt is handled (in 'AnalysisTask::interrupt()').
This interrupt is triggered for example, when the introduction dialog is closed
and the main Cutter window opens (after the optional 'aaa').
Now, if the binary file was analysed with 'aaa', and a lot of error cases were hit,
those error cases sometimes never called 'rz_cons_break_pop()' before returning from their function.
Although, of course, they should have to the `RzConsContext->break_stack` is in a proper state.
This means, when the main Cutter window opens binary files which trigger many error edge cases,
the `RzConsContext->break_stack` is not empty
(because of the not executed 'rz_cons_break_pop()').
This also means, that the last thing done, was setting 'RzConsContext->breaked = true'
(by 'AnalysisTask::interrupt()').
If Cutter wants to show some disassembly, it calls 'rz_core_print_disasm()' which checks
'RzConsContext == false' via 'rz_cons_is_breaked()'. This condition is never true, because
the flag was not reset to `false` because the stack was never empty.
So it returns before anything was disassembled.
Hence Cutter gets no disassembly text.
Fixes https://github.com/rizinorg/cutter/issues/2552
Fixes https://github.com/rizinorg/cutter/issues/3275
* librz: do not duplicate plugins
Plugins structures are statically defined at the file scope and not
dynamically allocated. Plugins should not allocate them either as
RzLibPlugin keeps a reference to them anyway.
* cmd: Fix summary of few "L" sub-commands
* util: start decluttering plugins handling
- Add Doxygen docs
- Remove unused API functions and make others internal only
- Use RzLibType enum for plugin type instead of int
* util: move dlopen/dlsym/dlclose to rz_sys
* util: make rz_lib_open/close return bool
* util: simplify rz_lib_add_handler and rz_lib_open*
* libs: implement rz_*_plugin_del to remove a plugin
* core: remove commands from RzCmd when removing plugins
* librz: call plugins 'fini' method when removing a plugin
* core/cmd: do not fail if the hashmap removal fails
When removing a group command, the inner command might have the same
name, thus it would result in trying to remove the same name twice.
Ignore it, as it is fine.
* librz: make RzCrypto plugins handling like the others
* librz/crypto: add rz_crypto_reset and use it
* librz: allocate the plugin structures before adding them
dbg->bits was checked in reg/windows_arm64.h, but when returning the reg
profile from the dmp plugin, this (deprecated) variable held the host
value when 64 was expected.
So it is better to move this check to the respective points where the
profile file is included.
RzDebug.bits often has nonsensical contents set from all kinds of
places. Specifically, when debugging fat binaries on arm64, it had a
value not matching the debuggee when the reg profile was loaded,
resulting in the arm32 profile being used.
The right way to determine the profile is to do it after attach, when
the cpu type of the debuggee is known.
