but thats related to QT6, is it possible that was connected to this issue somehow?
I would say extremely unlikely.
Starting off with the only bit we have
#0 0x0000000000562704 in AVL_TREE$_$TAVLTREE_$__$$_ROTATERIGHT$TAVLTREENODE ()
#1 0x0000000000561b04 in AVL_TREE$_$TAVLTREE_$__$$_BALANCEAFTERINSERT$TAVLTREENODE ()
This is very well matured code. The chances that this code itself contains a crashing bug... Extremely unlikely, to the point that I say its more likely you win the lottery jackpot twice in a row.... (Let me know if you do
)
Then that leaves 2 possibilities that I can think off.
1) Concurrent unprotected access from 2 threads (race condition)
2) Prior damage from a dangling pointer that overwrote those structures with its own data
(1) Can be further limited to "concurrent write access". Since this thread, wrote, and a read access by another thread would have only crashed the reading thread. (Well technically, it could have turned the reading thread into a dangling pointer, but then it would be (2)).
And, from my review, I am pretty certain that this does not happen. Well under normal operations, if the debugger had entered some invalid state already then that may be different, but then the trace is meaningless, and we don't know anything about how it entered the invalid state in first)
(2) A dangling pointer. That is a wide field... Technically that pointer could be in any code, even non debugger code.
But then, It always only struck, when the target hard crashed. If it was in other code, then it would most likely have done the damage to that structure anyway (independent of what the debugged process was doing). And at the latest when the debug session ended, the damage to the structure would always have crashed, even if the access violation never happened.
So then, the dangling pointer likely either
- happened in reaction to the debugger getting the signal that the target crashed.
- happened on some previous debugger event (pause at breakpoint, etc) that only happened when the crash was next (i.e. you always hit that breakpoint or did a single step) before the crash, and when the crash would be next something would be different, e.g. a watch would have a value that let to the dangling pointer...
Of course, calling a menu, that ended in an exception, could have created a dangling pointer...
But the likelihood that this always only happened when the target would crash next...?
Well, there is one possibility, that we haven't explored yet. (But its unlikely too)
You wrote:
Even the developer of the library found it hard to replicate
Well, he didn't replicate the Lazarus crash, he replicated the crash in the debugged library?
Actually, did he yet?
Because, what if the FpDebugger had failed before the crash? Then the debugger could have injected e.g. a breakpoint at the wrong location, and that could have caused the debug target to crash (so the targed would not have a bug, but the bug was injected by the debugger).
Then of course any event anywhere could have tripped the debugger, which would then have tripped the target.
But that would mean that when you get the target library crashing now, it would still be because of that. Only with different damage in the debugger, as it doesn't go down anymore.
Recent
