Re: [lmi] FFFFFFFF:FFFFFFFF

[Vadim Zeitlin]

On Sat, 12 Dec 2015 02:17:12 +0000 Greg Chicares <address@hidden> wrote:

GC> I wanted to test the patch below [0], so I added "false &&" just for
GC> testing (I wouldn't commit that part) and tried loading a complex
GC> census (perhaps one date field that varies by cell is complex enough).
GC> I got an error message that seems not to be very useful (so I'll
GC> remove the "lmi::TypeInfo(typeid(value))" part). Then, it crashed.
GC> IIRC, it was an access violation at an address that was all hex 'F',
GC> like FFFFFFFF:FFFFFFFF. My JIT debugger then printed an "abort, retry,
GC> ignore" message saying that it had tried to access invalid memory; I
GC> selected "ignore" a few times, and it finally finished. Then I copied
GC> its screen contents to this VM's clipboard and pasted that into
GC> IceWeasel, which froze for ten minutes until I killed it.
GC> 
GC> I report this in case it indicates a problem with wx.

 It's hard to answer this. On one hand, it could be seen as a problem with
wx, but OTOH I don't see how could anything be done about it. What happens
here is that a message box, i.e. a modal dialog, is shown from the code
which is (indirectly) called from wxEVT_PAINT handler. When this happens,
the census view window hasn't been validated, i.e. marked as being painted,
yet, because this is (and can) only (be) done once the event is fully
processed. So when the message box nested event loop is started, it soon
receives a new wxEVT_PAINT for the census view, asking to repaint it
again. Which shows another message box. Which starts another nested event
loop. Which receives another event... And I guess I need to stop here to
avoid freezing your email program for 10 minutes and crashing while trying
render an infinite sequence of these steps.

 The actually surprising thing is that under Windows 7 this sequence
somehow stops before resulting in stack overflow which you seem to be
observing. However trying to debug it first froze my debugger and then,
when it thawed and I (maybe wrongly) quit it, I ended up with an absolutely
unkillable and unattachable-to lmi process consuming 100% of (one of)
CPU(s) and window not reacting to any input stuck in plain middle of my
screen. So it seems like I'm going to need to reboot to get rid of it after
finishing this email :-(


 Anyhow, the recommended solution is to avoid showing message boxes from
any code called, directly or indirectly, from wxEVT_PAINT handler. This is
one of the advantages of using wxLogXXX() functions instead of using
wxMessageBox() directly (and, let me immodestly add, this is not accidental
but rather was one of the reasons for deciding to show the log messages
only during the idle time and not immediately). However we already
discussed using wxLog in the past and, while I don't remember the details,
you clearly were against doing it, so it could be nice to find some other
solution which could be used to mitigate this problem instead.

 Unfortunately I don't really have any good ideas about how to do this. We
could have a built-in counter of nested modal dialogs and do "something" if
it becomes "too high". The first obvious question is how high is "too high"
but I think that something like 20 could be safely used, i.e. should be low
enough to not result in any problems such as stack overflow or GDI
resources exhaustion yet, but high enough to never occur in any correctly
functioning program. Still, I could be wrong about the safe value for this
threshold and it would need to be tested exhaustively (in a VM this time as
I don't like rebooting more than once per year).

 The second and more difficult question is what, exactly, would we do if it
is reached? We can't show a message box to notify the user about the
problem, but just killing the program without any explanation doesn't seem
to be much more useful than the current behaviour of crashing. At least
like this the user knows that something went wrong unlike in the case of
the program simply disappearing. Linux kernel can output its messages in
Morse code using the keyboard LEDs when the video card is unusable, but I
am not sure about the Morse code knowledge prevalence among lmi users.

 So the best thing to do would probably be to return to the top level event
loop after (somehow) forcefully dismissing all the message boxes and hiding
all windows (so that no wxEVT_PAINT are generated for them any more) and
then telling the user that an infinite recursion was detected and broken
and that the program will now exit and that this should be reported as a
bug. It looks like it should be doable and it would be slightly better than
crashing, do you think it would be worth trying to do it this?

 In any case, this would just provide more information about the problem
but not solve it, the program would still die and would need to be modified
to stop showing the message boxes from the wxEVT_PAINT handler to avoid it.
Unless we just suppress the too deeply nested message boxes completely, but
I don't really see how could this work.


 To summarize, I don't really see this as a problem with wx, but, possibly,
as something to be improved. However I don't know how exactly to make this
better nor whether it's worth spending time on this.

 Regards,
VZ