Program hangs when I use trackPopupMenuEx

[xafizoff]

Current Behavior

Program hangs with trackPopupMenu(Ex).

Steps to Reproduce (for bugs)

My code is based on https://github.com/haskell/win32/blob/v2.6.1.0/examples/hello.lhs, except I do not do painting.

wndProc ::
       Graphics.Win32.HWND
    -> Graphics.Win32.WindowMessage
    -> Graphics.Win32.WPARAM
    -> Graphics.Win32.LPARAM
    -> IO Graphics.Win32.LRESULT
wndProc hwnd wmsg wParam lParam
    | wmsg == Graphics.Win32.wM_COMMAND && wParam == fromIntegral iDM_QUIT = do
        Graphics.Win32.destroyWindow hwnd
        return 0
    | wmsg == 0x007B = do
        showContextMenu hwnd
        return 0
    | wmsg == Graphics.Win32.wM_DESTROY = do
        Graphics.Win32.sendMessage hwnd Graphics.Win32.wM_QUIT 1 0
        return 0
    | otherwise = do
        Graphics.Win32.defWindowProc (Just hwnd) wmsg wParam lParam

showContextMenu :: Graphics.Win32.HWND -> IO ()
showContextMenu hwnd = do
    hMenu <- createPopupMenu
    pt <- Graphics.Win32.Misc.getCursorPos
    appendMenu hMenu mFT_STRING iDM_Exit (Just "&Exit")
    trackPopupMenuEx hMenu tPM_RIGHTBUTTON (fromIntegral $ fst pt) (fromIntegral $ snd pt) hwnd Nothing
    destroyMenu hMenu

A pop-up menu appears, but the program ends up freezing after that. I've tried to remove WM_COMMAND branch from wndProc, but this does not help.

Your Environment

• I'm using stack, tried resolvers lts-6.2, lts-16.8
• Versions used: 2.3.1.1, 2.6.1.0
• Operating System and version: Windows 10 Home

[Mistuke]

Hi @xafizoff can you give me a full source repro?

Also did you try with -threaded?

Thanks.

[xafizoff]

How to reproduce

> git clone https://github.com/xafizoff/haskell-win32-example.git
> cd haskell-win32-example
> cabal new-run haskell-win32-example-exe

Environment

> cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library

> ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

[xafizoff]

Also reproducible with Win32 v2.9.0.0. Sometimes you need to play with the cursor to freeze the program.

[Mistuke]

That looks like it's because you're blocking the message pump. trackPopupMenuEx is a blocking foreign call since it waits till the function returns. However in that time it's posting messages back the main Window expecting it to handle them, but the main loop is blocked so Windows marks the window as unresponsive.

(Graphics.Win32.tPM_RIGHTBUTTON .|. Graphics.Win32.tPM_NONOTIFY) will tell it not to try to post messages to the Window but handle them in it's own loop, but external events can still make the Window unresponsive. i.e. focus changes.

That said I don't remember enough about these Window APIs to suggest a complete solution, my initial thought it the pump must be created on a different OS thread, or the menu. a C tutorial on how to use this should have the right approach.

[xafizoff]

I don't know why it is blocking, probably due to Haskell RTS involvement, but similar C code works fine. So I ended up doing all GUI related stuff as a single foreign call. I just pushed it to github.

[merijn]

This is almost certainly the fault of this unsafe foreign import:
https://github.com/haskell/win32/blob/master/Graphics/Win32/Menu.hsc#L426-L427

I surmise from this thread of issues that c_TrackPopupMenu is a blocking function and thus should never be foreign imported unsafely. Unsafe foreign imports keep the RTS capability running Haskell code locked while the foreign code happens.

In multi-threaded runtime all capabilities must synchronise before GC can happen and those threads will block until synchronisation happens. Since the capability doing the unsafe foreign call can't synchronise this means all threads are blocked until the unsafe foreign call returns.

This is not the only dangerous unsafe foreign import, I found this issue after someone on IRC mentioned deadlocking when they used sleep, which also does an unsafe foreign import and suffers the same problem.

The solution is to not import these unsafely. Or even better remove all unsafe foreign imports from the package except those that are 100%, definitely known to be safe (i.e. non-blocking and short running).

[Mistuke]

Hello,

This is almost certainly the fault of this unsafe foreign import:
https://github.com/haskell/win32/blob/master/Graphics/Win32/Menu.hsc#L426-L427

hm I was sure I tried that, but most likely changed the wrong one. In any case I'll look into these again.

The solution is to not import these unsafely. Or even better remove all unsafe foreign imports from the package except those that are 100%, definitely known to be safe (i.e. non-blocking and short running).

Indeed, these UI bits were added as a mass import but clearly some slipped by.