search

jovibor / HexCtrl

Fully-featured Hex Control written in C++/MFC.
Other
167 stars 58 forks source link

Strange exception during long modify data operation (release build only) #51

Closed datasynergyuk closed 3 years ago

datasynergyuk commented 3 years ago

I found a strange bug in HexCtrl. I have only been able to reproduce the bug in virtual data mode when compiled as a release build. I cannot reproduce it in non-virtual data mode (e.g. sample application) or in debug builds.

To reproduce:

  1. Build application using virtual data mode
  2. Compile as release build
  3. Launch program and open a reasonably large file e.g. 4GB
  4. Perform data modify operation e.g. Fill random or fill with data etc
  5. Change focus to another window e.g. In my test case, this is easiest done by using Ctrl-Tab to move to another full screen application
  6. Wait a moment and then return to HexCtrl based application
  7. Application terminates
jovibor commented 3 years ago

Unfortunately I can not compile it: error C3861: 'RefreshDisplay': identifier not found Something #DSINTERNAL related, I guess.

datasynergyuk commented 3 years ago

My apologies. Please try again now.

When I re-tested, the problem was still present 3 from 4 launches. One time, I couldn't make it happen. This may suggest the problem is timing related. I may suggest adding a step to my procedure: 6b. After returning to the application, try moving the progress dialog a little. This seems to bring on the exception.

jovibor commented 3 years ago

Well, that's indeed a strange bug for me. It all happens because when changing the focus the system sends WM_PAINT message to the HexCtrl's main window even when it's totally obscured by the modal dialog. More strange, this only happens in the MDI application and not in the dialog based sample app.

In my understanding when a thread invokes any modal based window (MessageBox or CDialog::DoModal) it creates a new message loop and can not process/dispatch messages for the underlying windows (underlying message loop). And it's indeed the behavior of the Sample app (dialog based), but not the case for the MDI app.

So, either it's me who does not understand Windows` internals well enough, or it's some kind of Windows bug.

I fixed it by disabling WM_PAINT handling during modify operations, it seems to work fine as far as I could test it.

P.S. Windows version this was tested on is: 2004 (19041)

datasynergyuk commented 3 years ago

Thank you. Maybe this is some hidden MFC "magic" in an MDI app.