Rebasing does not work if subsequent launches have the module based at a different address #1232

Version and Platform (required):

• Binary Ninja Version: 6.0.10601
• OS: Ubuntu Linux (host running Binary Ninja)
• OS Version: 24.04.3 LTS
• CPU Architecture: x64
• Local or Remote Debugging: remote-linux platform, lldb-server in platform
  mode on an Ubuntu 26.04 LTS x64 VM, auto-install enabled

Bug Description:

When debugging a shared library, the Input File is the shared library (ELF 64-bit shared object, dynamically linked), and the Executable Path is an executable ELF that dlopen's that library at runtime.

debugger.autoRebase is at its default value true.
First launch after starting Binary Ninja: when the library is dlopen'ed, the binary view is correctly rebased to the library's remote base address. A breakpoint inside the library resolves, and when it is hit the disassembly correctly stops at the breakpoint, but the HLIL/pseudo-C views think that the IP is sitting a few hundred lines further (When I do "Jump to IP" through the menu, it jumps to a few hundred lines before the actual IP).

Screenshot

However, every subsequent launch in the same Binary Ninja process fails to reload the new ASLR base (I think), notice the error in the logs
[Default] Failed to rebase to remote base 0x<new base>. It seems both views agree on the IP this time though.
The view keeps the previous run's base I think. The stopped IP is still correct though, but Binary Ninja synthesises a function starting exactly at the IP (named sub_<IP>), and the pseudo-C shown for the stop is meaningless, it decompiles from the halt address rather than from the real function start.

Screenshot

This repeats for every launch thereafter. Closing and reopening Binary Ninja (and reconnecting to the debug server) restores the working behaviour, but again only for the first launch.

Timing detail that may help localise it: the "Failed to rebase" message appears at the moment the library is actually loaded I think (i.e. after triggering the code path that dlopens it), not at process launch. The reason I think this is the case, is because inbetween process start and the library being dlopen'd, it awaits for input. At this point, the error message does not yet show, only when I provide the input and it continues until the breakpoint the error appears.

Steps To Reproduce:

1. Start Binary Ninja and open a (stripped) shared library (.so) as the analysis target.
2. Debug Adapter Settings: adapter = LLDB, Input File = that .so, Executable Path = a host program that dlopens it at runtime. Configure debugServer ip/port for an lldb-server running in platform mode on a remote Linux host.
3. Set a breakpoint inside the library (I use an LLDB symbol-scoped pending breakpoint with --address-slide, since the library is stripped and is not mapped at process start). This is my command:
   breakpoint set -s xxxxxx.so -n xxxxx -R 0x2c965 -c (long)$rdx<-0x1000
4. Launch, and drive the program so that it dlopens the library and executes the breakpoint site. Observe: the view is rebased, and (at least) the disassembly view at the stop is correct.
5. Stop the debug session. Launch again (same Binary Ninja process) and drive it to the same breakpoint.
6. Observe: Log shows Failed to rebase to remote base 0x....

Expected Behavior:

With debugger.autoRebase enabled, the input binary view should be rebased to the module's current base on every module load, not only the first one in a Binary Ninja process. I think the assumed aslr base gets rebased correctly the first time but is not updated on subsequent runs or something. In other words, I'd expect the process to halt at the breakpoint's address in every type of view.

Binary:
N/A.

Additional Information:
N/A