Python - C++ Problem determination

wxPython Users
#1

I am experiencing spurious problems that show up as a C++ assertion exception.
It is always the same problem, it mostly occurs when I open the lid of my laptop during execution of my application. It might well have to do with a repaint operation when opening the lid.
I am using PyCharm and running on Windows 10 and fairly up-to-date versions of Python and wxPython.

My problem is, how do I find out what the problem is ?

wx._core.wxAssertionError: C++ assertion “(argtype & (wxFormatStringSpecifier::value)) == argtype” failed at C:\PROJECTS\bb2\dist-win64-py39\build\ext\wxWidgets\include\wx/strvararg.h(484) in wxArgNormalizer::wxArgNormalizer(): format specifier doesn’t match argument type

The above exception was the direct cause of the following exception:

SystemError: <class ‘wx._core.MouseEvent’> returned a result with an error set

There are no call stacks, not by C++ nor y Python

Cheers, Adrian

#2

I’m always amazed what this python wrapper filters out :stuck_out_tongue_winking_eye:: I would start with reinstalling the pad’s driver…

#3

I am not quite sure what you mean by your remark.
Results are the same when doing close and reopen the lid and sign-in, as well as using the
keyboard sequence and subsequent sign-in.

Cheers, Adrian

#4

Well, to me the exceptions suggest that your machine is generating corrupted data in the vicinity of the mouse pad (or at least ‘unexpected’ data), so you’ll have to find the culprit…

#5

Are you using MouseEvents in your application?

#6

This scenario causes the reported exception:

Start the test program and move the cursor outside of the program's window
Put the system to sleep, for instance by closing the lid of a laptop OR using the usual     keyboard sequence WindowKey - Power - Sleep
Sign-in to windows again
Move the cursor into the programs's window, the exception occurs

The test program is a heavily scaled down version of a larger OpenGL application, it is actually doing nothing other than creating a Window and setting up a few event handlers.
The app is started from within the PyCharm IDE environment.
Often, the full OpenGL app is terminating when this situation occurs, which is irritating indeed.

Test program:

import wx

class MainFrame(wx.Frame):

    def __init__(self):
        wx.Frame.__init__(self, None, title="C++Bug ?", id=4711, size=(500, 300))

        self.Bind(wx.EVT_SIZE, self.onSize)
        self.Bind(wx.EVT_PAINT, self.onPaint)

        self.Bind(wx.EVT_MOTION, self.onMotion)

    def onSize(self, ev):
        print('OnSize()')

    def onMotion(self, ev):
        # print('onMotion()')
        pass

    def onPaint(self, event):
        print('onPaint')

    def OnQuit(self):
        print('MainFrame() OnQuit')

if __name__ == "__main__":
    app = wx.App()
    frame = MainFrame()
    frame.Show()
    app.MainLoop()
#7

Yes I do.
See the test program below

#8

Does it make a difference if you create a wx.PaintDC in the onPaint handler? On Windows you should always create a paint DC in the EVT_PAINT handler, even if you don’t do anything with it.

#9

I’ve done what you said, but not within PyCharm (too heavy for me), and there is no problem whatsoever…

#10

Hi Robin,

I have added a PaintDC() context, and added a DrawRectangle() as well like:

    dc = wx.PaintDC(self)
    dc.DrawRectangle(50, 60, 90, 40)

The same exception occurs, with or without the DrawRectangle() statement when the scenario described is followed.
I think, not having to paint anything is a valid case, isn’t it ?

As to da-dada’s remark about a possibly failing buggy laptop driver, from now on I will use the WindowKey - Power - Sleep sequence to get the system to sleep.

The full app I am working on does not use a PaintDC() at all. It uses a GLCanvas in single buffer mode. All 2D objects are redrawn when the onPaint handler is called. It works fine but gets killed when I run the test scenario, or the system goes into sleep because I ran away for some errant.

Robin, how should I proceed from Here ?

Cheers, Adrian

#11

The creation of the PaintDC is what signals to the OS that the event has been handled and the widget has been refreshed. It looks like it may not be an issue any longer, but in the past if there wasn’t a PaintDC created then Windows would send another paint event almost immediately and the application would spend all its idle time doing unnecessary paints.

Sometimes wxPython isn’t able to report the C++ assertion failure until some unrelated bit of Python code is executed. That appears to be the case here. Try adding the following to change how the C++ asserts are handled. It may give you a better idea of the context of the error.

    theAppObject.SetAssertMode(wx.APP_ASSERT_DIALOG)
#12

Thanks Robin.

This helped me in that I now get a decent exit code :
Process finished with exit code -1073740771 (0xC000041D)

There are quite a lot of Google entrees on this but I don’t quite understand what they are talking about. I mean, the exception talks about a formatting error in a printf() call, but who is producing this bad data ?

From the beginning I had the feeling that my problem emanates from deep down in wxWidgets, if not Windows. I decided to get Visual Studio and wxWidgets and looked for a simple simple wxWideget app.

Doublemax, moderator of the wxWidgets forum, mentioned many times that using the sample.minimal app is the easiest way to start with wxWidgets. Indeed, he is absolutely wright. And by using my test scenario I could recreate my problem right away.

Executing minmal.exe with VC debugger gives a lot of data about this problem, the last entry of the call stack trace is [external code], which probably means somewhere in Windows.

So I guess I have to talk more to the wxWidget guys.

Cheers, Adrian

#13

Defect #19080 has been confirmed, patch is available.

#14

Thanks. I’ll update as soon as I can and get a new snapshot build that includes the wxWidgets fix.