Valgrinding to get exp. Testing with "r2 -Aqcq /bin/ls"
Before:
definitely lost: 22,735 bytes in 250 blocks
indirectly lost: 23,542 bytes in 605 blocks
possibly lost: 2,464 bytes in 7 blocks
still reachable: 3,876,216 bytes in 80,761 blocks
After:
definitely lost: 25,216 bytes in 58 blocks
indirectly lost: 24,830 bytes in 739 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 20,105 bytes in 34 blocks
The "goto beach" (named like that for consistency) change resulted in
freeing most of the "still reachable" stuff on quit, which also moved
stuff out of "possibly lost", so.. it looks like it's leaking more now.
Yay.
This was originally used to cause a seek to the next block prior to
reading such that successive calls to r_core_block_read() would progress
through memory one block at a time. This was broken, though, by commit
452669d941 ("more cleanup in r_core_block_read") when when it used
`next' to directly calculate the offset rather than via a seek.
Only one call site remains that attempts to read the next block instead
of the current, and this probably was not even observable due to the
"hacky fix" added in commit 3bfa61946e ("Cleaner pvj, fix tinype load,
and honor 'ao N's").
The current of semantics of `next' appear to be broken and there is very
little dependence on it. If the original behavior should be restored
anywhere, it would be much better to add a new function, or just do the
seek explicitly, rather than parameterizing r_core_block_read() on it.
Commit 57b199789d ("Reread block after undo seek. Fixes dbg.status
issue") reads the *next* block into the buffer rather than the current.
This breaks backwards seeking as can be seen in the following example:
$ r2 -N malloc://0x4000
[0x00000000]> b 64
[0x00000000]> wb 38
[0x00000000]> s 64
[0x00000040]> wb deadbeef
[0x00000040]> s-32
[0x00000020]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000020 dead beef dead beef dead beef dead beef ................
0x00000030 dead beef dead beef dead beef dead beef ................
0x00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
[0x00000020]> s+16
[0x00000030]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000030 3838 3838 3838 3838 3838 3838 3838 3838 8888888888888888
0x00000040 dead beef dead beef dead beef dead beef ................
0x00000050 dead beef dead beef dead beef dead beef ................
0x00000060 dead beef dead beef dead beef dead beef ................
The first block to a string of ASCII '8' bytes and the second to
0xdeadbeef. We then seek backwards 32 bytes from our current 64 byte
offset but a dump at the resulting offset shows data from half way into
the second block (i.e., offset 0x60.) Dumping again after seeking 16
bytes forward shows the expected last bit of the first block. Clearly
the intent was to reread the current block, not the next block, after an
undo or backward seek.
NOTE: The above example will only work after applying the previous
commit as rereading the buffer when displaying the prompt hides this
bug.
Additionally, since the commit intended to reread the buffer only after
an undo seek, do not do this at all on a backward seek.
Commit 3bfa61946e ("Cleaner pvj, fix tinype load, and honor 'ao N's
help") added a hack to reread the current block when printing the
prompt. This has the drawback of causing scripts loaded via the `-i'
command line option to potentially behave differently than reading the
commands via stdin. Remove the hack and fix the bugs.
This is an empty file because I (DanTheColoradan) was unable to
obtain any ordinal information. I tried two versions:
- 9.0.30729.1
- 9.0.30729.6161
Both were downloaded from dll-files.com. I also tried a version
from MS Windows 10, but I don't know what version it was.
This change should close#5486.
