On 02/07/2018 10:41 AM, Andreas Gampe wrote:
> Stack Trace:
> RELADDR FUNCTION FILE:LINE
> 7e253 top_common+6387 external/toybox/toys/posix/ps.c:1420
> 7c413 top_main+555 external/toybox/toys/posix/ps.c:1666
> 1f7db toy_exec+311 external/toybox/main.c:
Stack Trace:
RELADDR FUNCTION FILE:LINE
7e253 top_common+6387 external/toybox/toys/posix/ps.c:1420
7c413 top_main+555 external/toybox/toys/posix/ps.c:1666
1f7db toy_exec+311 external/toybox/main.c:169
1ef77 toybox_main+91 external/toybox/main.c
Argh. I should have given you the full failure message (or be more
explicit in the suggested solution) - sorry, my mistake. ASAN
complains about a heap buffer overflow, not a null pointer access
(which should always kill top, not just under ASAN). Your fix was:
struct carveup *otb = old.tb ? *ol
Thanks for the explanations!
Now I understand.
I thought it was related to the search results somehow...
I didn't consider the local argument expansion.
2018-02-08 5:23 GMT+01:00 Robert Thompson :
> This is because the wildcard argument to -iname needs *not* to be
> expanded by the shell. It nee
Here's a symbolized ASAN abort after the import of your fix:
==7750==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x004b4be8 at pc 0x0056c377f290 bp 0x007ff7193f50 sp
0x007ff7193f48
READ of size 8 at 0x004b4be8 thread T0
Stack Trace:
RELADDR FUNCTION FIL
If we have a 15-byte name, we don't know whether comm actually matches
or is a truncated form of a longer name that has a common prefix.
For example, with "this-is-a-very-long-name-that-is-too-long", we shouldn't
match "this-is-a-very-" (but the old code would).
Bug: http://b/73123244
---
lib/li
okay, ignore that patch (not least because it was an unrelated old
patch that's already been applied) and try this one instead... turns
out we have two separate pidof bugs on Android. which is only fitting,
because two separate bugs were raised today (though they were both for
this latter bug, not