[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] An irreproducible anomaly
From: |
Greg Chicares |
Subject: |
Re: [lmi] An irreproducible anomaly |
Date: |
Tue, 14 Jun 2016 21:50:31 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 |
On 2016-06-14 21:16, Vadim Zeitlin wrote:
> On Tue, 14 Jun 2016 21:03:14 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> On 2016-06-14 20:54, Vadim Zeitlin wrote:
> GC> > On Tue, 14 Jun 2016 20:04:08 +0000 Greg Chicares <address@hidden> wrote:
> GC> [...]
> GC> > GC> My hypothesis is that the wxUpdateUIEvent pump has failed. But
> GC> > GC> I find no call to SetUpdateInterval() or SetMode() in lmi that
> GC> > GC> could cause UpdateUI events to stop flowing.
> GC> >
> GC> > Yes, I don't see why would this happen. If you can reproduce this
> again,
> GC> > could you please check if the in-place text edit control in the census
> view
> GC> > remains open while the "Edit" dialog is shown or is it closed first for
> you
> GC> > too?
> GC>
> GC> I believe the report stated that in-place edit control remained open.
>
> This does seem to confirm my idea that we're somehow ending up showing the
> dialog from inside wxYield() call. As calling wxSafeYield() from inside
> wxYield() does nothing (which was considered to be "safer" than yielding
> recursively and crashing with stack overflow), this could explain the
> observed symptoms. I still don't see how can we end up inside wxYield() in
> the first place though... Had you done something else before seeing this
> problem? I suspect that the real bug must be elsewhere, and this is just a
> consequence of it, but it's nothing more than a suspicion unfortunately.
> But if you could remember which operations you had performed before seeing
> the bug, it might provide a way of reproducing it.
I only saw it once myself, when I was trying to reproduce it while talking
with Kim on the telephone. I didn't have lmi open at all, so I started a
single instance just to see whether I could reproduce the anomaly. I ran
through a broad variety of steps before I saw anything weird--e.g.:
- editing the field in-place in the census manager
- pasting into it
- copying from it and pasting back in repeatedly
- toggling "Census | {Fixed,Variable} column width"
- resizing the field with the mouse
and then popping up the tabbed dialog by
- right-clicking the same cell and choosing "Edit cell..."
- right-clicking a different cell and choosing "Edit cell..."
- clicking the magnifying-glass button on the toolbar
- equivalent menu commands with the mouse, with alt-key accelerators,
and with Ctrl-Shift-Whatnot
but I've repeated all those things numerous times and have seen the
anomaly only once.
If you can think of some extra sanity check that we might build in,
perhaps activated only by '--ash_nazg' because end users don't know
about that option, I'd be glad to add it. Otherwise, I guess we just
have to wait until someone formulates a reproducible test case.