address and instruction bytes column overlap after reopening

[sorokin]

If I make address column too small and then close edb and then open it again, I get disassembly view that looks like this:

If I trace the values of l1, l2, l3, l4 in DrawingContext I will get something like this: (165 380 231 1194), while before reopening it was (165 190 223 11940). As I found out the line2_ loaded correctly in QDisassemblyView::restoreState and then is reset to 0 in QDisassemblyView::setRegion.

At first my diff to fix the problem was:

$ git diff --cached
diff --git a/src/widgets/QDisassemblyView.cpp b/src/widgets/QDisassemblyView.cpp
index fc44ae2d..eaafca09 100644
--- a/src/widgets/QDisassemblyView.cpp
+++ b/src/widgets/QDisassemblyView.cpp
@@ -535,10 +535,6 @@ void QDisassemblyView::setRegion(const std::shared_ptr<IRegion> &r) {
                setAddressOffset(region_ ? region_->start() : edb::address_t(0));
                updateScrollbars();
                Q_EMIT regionChanged();
-
-               if (line2_ != 0 && line2_ < autoLine2()) {
-                       line2_ = 0;
-               }
        }
        update();
 }

You might compare it with this commit 8f2c83137a4432a948778c8d9b5c6bf6ed905e57. :-)

Now the question is what is the proper way of fixing the problem. One might argue that writing line2_ without updating line3_ and line4_ breaks class invariants. And updating them too would fix the visual glitch, but I would say that resetting column widths set by user is not a good behavior.

To fix the visual glitch, but also to address #492, I would like to suggest having different column width settings for 32 and for 64 bit modes.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.