we have been observing that, sporadically, an internal callback set for a breakpoint is not invoked. We are setting an hidden breakpoint in the renderscript plugin through:
breakpoint = target.CreateBreakpoint(symbol_address, true, false);
breakpoint->SetCallback(rs_callback, rs_baton, true);
where symbol_address refers to a runtime function x in the debugged process.
The callback is properly invoked 99% of the time that the process calls the function x, though occasionally it is missed, while both prior and further calls are recorded.
This issue seems to occur only in android/mips32, though we are not able to exclude whether other platforms are affected.
Has anyone experienced a similar issue or can provide any suggestion to what might be worth to watch for that might cause this behaviour?
The only similar case we ran into was a situation where our kernel was playing tricks and essentially re-loading a module at the same location. So what would happen is:
1 - kernel would load a.out's .text section at 0x10000
2 - LLDB would notice via a module loaded notification and would set a breakpoint at 0x10000 + offset
3 - kernel would load a.out's .text section at 0x10000 but erase all changes, like the breakpoint we set above in step 2
4 - We would get a load notification for a.out's .text section again, but we would see that the location didn't change, so the module doesn't send out a module loaded notification and we would lose the breakpoint for good
What our dynamic loader had to do was to know that this can happen and if you get a load notification for a section, send a module unloaded for a.out first (which would clear the breakpoint), and then send out a module loaded notification and the breakpoint would get set correctly once again when the section was reloaded.