Community
Participate
Working Groups
Created attachment 176526 [details] patch for DisassemblyDocument.java fixing mismatch between computeIndexInPositionListFirst() and addModelPositionFirst() 1] if AddressRange [0:0xFFFFFFFF] is the first item passed to this algorithm 2] and then Address 0xFFFFFFFF is passed to it (and something similar is being seen when debugging DisassemblyDocument.java) then the algorithm will fall out of the first loop with left == 1, mid == 0, and will thus set idx == 0. at that point, the first value [0xFFFFFFFF:0] is retrieved, then "if (0xFFFFFFFF.compareTo(0xFFFFFFFF+0) > 0)" is performed, which will fail, and then "else (0xFFFFFFFF.compareTo(0) == 0)" is performed, which will also fail. and so idx == 0 is returned ... which leads to: if (idx < list.size()) { AddressRangePosition nextPos = list.get(idx); assert nextPos.fAddressOffset.compareTo(pos.fAddressOffset.add(pos.fAddressLength)) == 0; } this assert fails because nextPos will be [0,0xFFFFFFFF], and so 0.compareTo(0xFFFFFFFF+0) will != 0 . see the attached patch for code that would rectify this in the caller, and has been nominally tested to solve the problem where the disassembly view does not populate the first time it is opened.
Could you attach a backtrace of the AssertionError? I would like to understand the call chain. Why don't you fix this in computeIndexInPositionListFirst()? It just seems to be missing a case.
(In reply to comment #1) > Could you attach a backtrace of the AssertionError? I would like to understand > the call chain. call chain: DisassemblyDocument.addModelPositionFirst(AddressRangePosition) line: 678 DisassemblyDocument.insertInvalidAddressRange(int, int, BigInteger, BigInteger) line: 1267 DisassemblyView(DisassemblyPart).addressSizeChanged(int) line: 1712 DisassemblyBackendDsf$6$1.run() line: 275 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 4041 Display.readAndDispatch() line: 3660 > Why don't you fix this in computeIndexInPositionListFirst()? It just seems to > be missing a case. answer: i actually would have preferred to fix computeIndexInPositionListFirst(), and i even attempted to do so. but trying to account for the method with which addModelPositionFirst() calls computeIndexInPositionListFirst(), i broke the cases of the other four callers i found. the result was that chunks of disassembly (it looked like every other line in mixed mode) went missing when this was fixed to account for the case described at the beginning of the description of this bugzilla entry. it also stopped scrolling altogether in certain cases. therefore, given that sticking with attempting to modify computeIndexInPositionListFirst() would also cause changes in the other four referencing callers, and given that the assert was only happening in addModelPositionFirst(), and given that only addModelPositionFirst() was calling computeIndexInPositionListFirst() with the addr+len (whereas the others all seem to call it with the addr w/o adding the len) … it seemed appropriate to me to consider this function to be the location of the patch. i guess the other thing in favor of this fix is that, for me, it actually fixes the problem i see where the disassembly window comes up blank, and continues to allow viewing of disassembly without other problems.
Created attachment 176784 [details] Alternative fix Could you try this fix? I am not able to reproduce this bug myself.
the alternate appears to solve the problem.
(In reply to comment #4) > the alternate appears to solve the problem. Excellent. Thanks for testing it. Do you need the fix in 7.0.1?
Committed the fix to HEAD and cdt_7_0.
