I am debugging the standalone version of Spidermonkey (Firefox JS Engine) and if I try and step over the particular source line it doesn't work and just continues running to the next breakpoint. Only happens on this particular line so far, not sure what's so special about it. I have isolated the offending commit to be this one. In the previous commit line step over works as intended.

edit: And it looks like "ctrl_key_from_process_vaddr_range" is called from "d_trap_net_from_thread__step_over_line"

ctrl_key_from_process_vaddr_range(
   CTRL_Handle  process = { ... },
   Rng1U64  vaddr_range = { ... },
   int zero_terminated = 0,
   u64 endt_us = 27377446074,
   int * out_is_stale = 0000003264781E50)
ctrl_process_memory_slice_from_vaddr_range()
d_trap_net_from_thread__step_over_line()
d_tick()
rd_frame()
frame()
update()
entry_point()

edit: ok interesting on the buggy commit "d_trap_net_from_thread__step_over_line" produces 4 breakpoints but on the previous commit it produces 5.

edit: Ok, the difference between the output of "ctrl_process_memory_slice_from_vaddr_range" in the buggy commit the last 8 bytes are zero. Whereas, in the previous commit there is data there.

edit: In "ctrl_process_memory_slice_from_vaddr_range" (called from "d_trap_net_from_thread__step_over_line") it attempts to read 2 pages. But on the second call to "hs_data_from_hash" the size from this call is 0. The any_byte_bad flag is set to true.

edit: Ok, this is making more sense. The instruction "{e9 3a 00 00 00} jmp 0x00007FF7309DA03F (PerformPromiseAllSettled)" happens to be the start of a new page (0x00007ff7309da000). But it's value is {00 00 00 00 00} because the call to "hs_data_from_hash" fails. Normally when this read is valid "d_trap_net_from_thread__step_over_line" would disassemble the jump and place a breakpoint on it's jump target (0x00007FF7309DA03F).