#88 win32event.MsgWaitForMultipleObjectsEx() segfaults


win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see:
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic

The patch also contains a very basic test.


  • Ziga Seilnacht

    Ziga Seilnacht - 2008-10-02

    Ok, the old version segfaults even if you have nonempty list:

    >>> import win32event
    >>> event = win32event.CreateEvent(None, 0, 0, None)
    >>> res = win32event.MsgWaitForMultipleObjectsEx([event], 0, 0, 0, 0) -> segfault

    This is on Windows XP SP3. Since it looks that this function was
    never usable, I attach a new patch that also changes its interface.

    The native MsgWaitForMultipleObjectsEx() function doesn't have a
    fWaitAll parameter, but the Python wrapper did have it and never did
    anything with it. So this updated patch simply removes it.
    File Added: MsgWaitForMultipleObjectsEx2.diff

  • Ziga Seilnacht

    Ziga Seilnacht - 2008-10-02

    Of course, I forgot to update the test in the second version of
    the patch... Here is the third, and hopefully last version.
    File Added: MsgWaitForMultipleObjectsEx3.diff

  • Mark Hammond

    Mark Hammond - 2008-10-02

    Thanks - I checked the changes in:
    Checking in src/win32event.i;
    new revision: 1.10; previous revision: 1.9
    Checking in test/test_win32event.py;
    new revision: 1.2; previous revision: 1.1

    I'm guessing the lack of a calling convention on the function pointer was the problem.

    FYI, the _WIN32_WINNT macro isn't reliable in this context - often we use a higher version to get the structure definitions, but still take care to dynamically load the function pointers that don't exist in all versions we support. In this case though you are correct - the function is now available in all versions we support, so I just nuked the dynamic load code too rather than verifying it was the calling convention.


  • Mark Hammond

    Mark Hammond - 2008-10-02
    • status: open --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks