An access violation can occur in the Disasm function on the following line: TABLE_1[PInst^.Addr^](PInst);
This happens because an invalid address escapes from UnivDisasm.Internal.Common.DecodeJ.
The access violation in Disasm causes memory allocated to TInstruction.Mnem to be leaked.
I can see that addresses used to be tested, but this was then made optional (effectively disabled). I don't have enough background knowledge to say whether or not there's a problem with the way the address is calculated in DecodeJ.
Testing and setting invalid addresses to nil in DecodeJ fixes the memory leak, but raises several access violations. This is problematic if you're using UnivDisasm as part of the DebugEngine library, because the debugger will hook a bunch of access violations every time a stacktrace is generated.
An access violation can occur in the
Disasmfunction on the following line:TABLE_1[PInst^.Addr^](PInst);This happens because an invalid address escapes fromUnivDisasm.Internal.Common.DecodeJ. The access violation inDisasmcauses memory allocated toTInstruction.Mnemto be leaked.I can see that addresses used to be tested, but this was then made optional (effectively disabled). I don't have enough background knowledge to say whether or not there's a problem with the way the address is calculated in
DecodeJ.Testing and setting invalid addresses to nil in
DecodeJfixes the memory leak, but raises several access violations. This is problematic if you're using UnivDisasm as part of the DebugEngine library, because the debugger will hook a bunch of access violations every time a stacktrace is generated.