Linux LLDB fails to update the value of bytes which have breakpoints on it

On Linux, when writing to memory, the bytes where there are breakpoints on it are left unchanged. The expected behavior is to report the newly written value -- despite the actual byte value is 0xc3. This is a LLDB internal bug so I have no way to fix it. This bug seems to be only affecting Linux, not macOS. I am yet to test it on Windows.

This causes spurious unit test failure in test_memory_read_write. Since we are writing to the code at the entry point, where there happens to be a breakpoint, the value read back is different from what we write.

I can reproduce this directly in lldb:

$ lldb '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld' 
(lldb) target create "/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld"
Current executable set to '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld' (x86_64).
(lldb) b main
Breakpoint 1: where = helloworld`main, address = 0x0000000000001169
(lldb) r
Process 134979 launched: '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld' (x86_64)
Process 134979 stopped
* thread #1, name = 'helloworld', stop reason = breakpoint 1.1
    frame #0: 0x0000555555555169 helloworld`main
helloworld`main:
->  0x555555555169 <+0>: endbr64 
    0x55555555516d <+4>: pushq  %rbp
    0x55555555516e <+5>: movq   %rsp, %rbp
    0x555555555171 <+8>: subq   $0x20, %rsp
(lldb) memory write 0x555555555169 -s 4 aaaaaaaa
(lldb) x/4xw 0x555555555169
0x555555555169: 0xaaaaaaf3 0xe5894855 0x20ec8348 0x48ec7d89

It can be seen the first four bytes become 0xaaaaaaf3 after the memory write, instead of the expected value 0xaaaaaaaa. I need to file this bug to LLDB.

Start with the failing test_memory_read_write and reproduce the behavior using the provided LLDB session against the helloworld binary. Compare the bytes read after writing at the breakpoint address; resolution would require an actionable fix or confirmed upstream LLDB change, which this issue does not identify.