STR #3359: Hangs in PeekMessageW in Fl_win32.cxx::fl_wait()

STR #3359

Application:	FLTK Library
Status:	2 - Closed w/o Resolution
Priority:	4 - High, e.g. key functionality not working
Scope:	2 - Specific to an operating system
Subsystem:	None
Summary:	Hangs in PeekMessageW in Fl_win32.cxx::fl_wait()
Version:	1.3.3
Created By:	andek
Assigned To:	AlbrechtS
Fix Version:	Will Not Fix
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	andek 12:59 Nov 28, 2016

With the FLTK example application "shape" running, when logging into the TeamViewer 11.0.66695 application (probably with other versions as well), FLTK hangs at the PeekMessageW call in Fl_win32.cxx::fl_wait(), more specifically in this line of code: while ((have_message = PeekMessageW(&fl_msg, NULL, 0, 0, PM_REMOVE)) > 0) When logging into one's account in the TeamViewer, the application indeed injects itself into other open windows, adding a horizontal double-arrow icon in the title bar, so this probably reveals some problem in FLTK or there's a bug in TeamViewer. If so it would be necessary to avoid this hang in some way even if the bug is in TeamViewer. Pausing in a Visual Studio debug session reveals a call stack including TeamViewer DLLs: nvoglv64.dll!00000000545e26b6() Unknown nvoglv64.dll!00000000543a7df4() Unknown nvoglv64.dll!00000000545f10c8() Unknown nvoglv64.dll!00000000545de188() Unknown [External Code] tv_x64.dll!00007ff836dbcc41() Unknown tv_x64.dll!00007ff836dbd1cd() Unknown [External Code] fl_wait(double time_to_wait) Line 422 C++

#2	greg.ercolano 13:23 Nov 28, 2016

Some thoughts that might help you determine the problem, as it's unknown when the devs will be able to look into this: I personally don't know much about our low level windows driver code, esp. event handling stuff, but it sounds like the PeekMessageW function underlines it works with the events from the "current thread" when used as we call it (with NULL for the second "hWnd" argument): https://msdn.microsoft.com/en-us/library/windows/desktop/ms644943%28v=vs.85%29.aspx Just a guess; perhaps TV's injection code is changing the thread context somehow, such that our 'hwnd=NULL' is triggering PeekMessageW to wait for events from an unrelated window..? I suppose one way to rule this out would be to replace that NULL with an actual value.. perhaps the value of Fl_win32's "fl_window" global.., e.g. // the current window handle, initially set to -1 so we can correctly // allocate fl_GetDC(0) HWND fl_window = NULL; I have no idea for sure. Or perhaps safer: add a printf() around that loop that prints the current thread's window value just before the Peek call, (the one PeekMessageW() supposedly falls back to when NULL is used for hWnd) and see if it changes when the hang happens. I don't know how to do this, but just reading the docs for the Peek call makes me think this is perhaps possible, as the hWnd=NULL argument must be flagging this behavior internally. I can't think why an Fl_Gl_Window might cause this, but perhaps there's a bug in our Fl_Gl_Window specific code that is affecting this. You might want to check: is there any indication in the debugger that the hung Peek call is in a thread other than the main thread? Even if you don't use threads, somehow a thread might be created elsewhere that is causing fl_wait() to be called outside of the main thread.

#3	AlbrechtS 16:28 Nov 28, 2016

I built up a test scenario with two Windows 10 machines, one with TeamViewer 11.0.63017, the other with 11.0.66695 (latest version, same as reported by OP). I started test/shape (FLTK 1.3.4) on both machines and started TeamViewer in both "directions", i.e. machine1 controlling machine2 and vice versa. I could use test/shape on both machines locally or with the remote control, hence I could not replicate the problem. I did not "log in" as the OP described and I don't see the TV double arrow as the OP describes, hence I don't know if TV injects its DLL's in this test. I don't have a TeamViewer account so I can't "log in". @Greg: AFAICT we need messages related to different windows [1] and maybe also messages unrelated to any window, so I don't think we can change the hWnd argument. ------ [1] We always have a hidden "timer window" and we can have several simultaneously open windows that can be hidden, exposed, get focus, lose focus, etc. ------ We should also pay attention to the fact that Andreas reported that there is also an Nvidia driver (dll) involved. This fact, together with the observation that maybe only Fl_Gl_Windows are affected, makes me think that the culprit could also be the Nvidia driver/dll. So we have three possible candidates that may be causing the behavior (without any order in mind): (1) FLTK (2) TeamViewer (3) Nvidia @Andreas: - Can you start a TeamViewer connection between two machines (client and server) without "logging in" to the TeamViewer account? I did it this way. - Do you see the same effects if you do that? - Can you replicate the effect on other client machines, maybe with different graphics (not nvidia)? - Can you say anything about CPU usage of the hanging process? Is it in a waiting state (little CPU usage), or is it in a tight (polling) loop (high CPU usage)?

#4	andek 04:31 Dec 02, 2016

Answers below: - Can you start a TeamViewer connection between two machines (client and server) without "logging in" to the TeamViewer account? I did it this way. - Do you see the same effects if you do that? No, I have tried this way but I can only reproduce when I log in. A TV account is free, so easy to test. I only see the double-arrow icons injected when logging in as well. It's apparently called QuickConnect in TeamViewer and it can be disabled in the TV advanced options. This removes the problem, but since it being enabled is the default clients will continue to suffer from this issue. - Can you replicate the effect on other client machines, maybe with different graphics (not nvidia)? I tried it on my laptop with nVidia and it crashed. But when switching to the Intel graphics on the same laptop it's okay. So yes, this seems to be a combination of nVidia's drivers and TeamViewers injection then. I tried updating to the latest nVidia drivers but to no avail - still hangs. - Can you say anything about CPU usage of the hanging process? Is it in a waiting state (little CPU usage), or is it in a tight (polling) loop (high CPU usage)? It seems to be a busy wait or some high CPU usage anyway, on my quad with hyper-threading it takes 12-13% so one full core. I have a feeling that I've seen this in other situations than logging into TV, but I can't guarantee that's the case. But here we at least have a repeatable case on my desktop and laptop, both running Geoforce. If you get a free TV account and have nVidia I hope you can reproduce as well.

#5	AlbrechtS 10:13 Dec 07, 2018

What is the status of this STR, does the issue still exist or did anything change? Is there any (debug) information that might help finding the cause?

#6	andek 10:50 Dec 07, 2018

It seems TeamViewer removed this feature. I can't find it in version 13 and I've seen others searching for it with no luck as well. So I don't think it's a problem anymore in practice.

#7	AlbrechtS 11:15 Dec 07, 2018

Thanks for your reply - I conclude we can close this STR. Okay?

#8	andek 11:23 Dec 07, 2018

Yes, okay with me!

#9	AlbrechtS 11:53 Dec 07, 2018

Closing STR in accordance with OP. Thanks.