We're having a strange problem here, an infinite loop happens on a customer's machine just after the main form is created. It doesn't happen when the program is run inside a debugger and it only happens on the customer's machine(s), so it's probably related to their Windows configuration.

The infinite loop is not in our code (probably happens with HandleNeeded() is called for the main form). When I attach gdb manually when the program is run outside the debugger I can get a stack trace that shows the loop:

(gdb) thread 1
[Switching to thread 1 (Thread 4484.0x2bc8)]
#0 0x76d2566b in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll (gdb) bt
#0 0x76d2566b in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll #1 0x76d1b387 in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll #2 0x005076ab in CALLDEFAULTWINDOWPROC (WINDOW=592304, MSG=48, WPARAM=-854972773, LPARAM=0) at ./win32/win32callback.inc:97
#3 0x0050bb80 in TWINDOWPROCHELPER__DOWINDOWPROC (this=0xf3e7e1c) at ./win32/win32callback.inc:2419 #4 0x0050c4fb in WINDOWPROC (WINDOW=592304, MSG=48, WPARAM=-854972773, LPARAM=0) at ./win32/win32callback.inc:2673 #5 0x76d334bb in USER32!AddClipboardFormatListener () from C:\WINDOWS\System32\user32.dll #6 0x76d25913 in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll #7 0x76d1b387 in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll #8 0x72e6fd6d in ?? ()
#9 0x72e6f8ef in ?? ()
#10 0x76d334bb in USER32!AddClipboardFormatListener () from C:\WINDOWS\System32\user32.dll #11 0x76d25913 in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll #12 0x76d1b387 in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll #13 0x005076ab in CALLDEFAULTWINDOWPROC (WINDOW=592304, MSG=48, WPARAM=-854972773, LPARAM=0) at ./win32/win32callback.inc:97
#14 0x0050bb80 in TWINDOWPROCHELPER__DOWINDOWPROC (this=0xf3e7cf4) at ./win32/win32callback.inc:2419 #15 0x0050c4fb in WINDOWPROC (WINDOW=592304, MSG=48, WPARAM=-854972773, LPARAM=0) at ./win32/win32callback.inc:2673 #16 0x76d334bb in USER32!AddClipboardFormatListener () from C:\WINDOWS\System32\user32.dll #17 0x76d25913 in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll #18 0x76d1b387 in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll #19 0x72e6fd6d in ?? ()
#20 0x72e6f8ef in ?? ()
#21 0x76d334bb in USER32!AddClipboardFormatListener () from C:\WINDOWS\System32\user32.dll #22 0x76d25913 in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll #23 0x76d1b387 in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll #24 0x005076ab in CALLDEFAULTWINDOWPROC (WINDOW=592304, MSG=48, WPARAM=-854972773, LPARAM=0) at ./win32/win32callback.inc:97
#25 0x0050bb80 in TWINDOWPROCHELPER__DOWINDOWPROC (this=0xf3e7bcc) at ./win32/win32callback.inc:2419

It carries on like this until you stop with ctrl-c. I was wondering if this rang a bell for anyone? I'm running on the fixes_2_0 branch now, but the problem existed with fixes_1_8 too.

Is there anything I can do to help get to the bottom of this? Will rebuilding the LCL with MSG_DEBUG help?

Henry

Rebuilding the LCL with MSG_DEBUG shows that it has something to do with WM_SETFONT:

Done: Main form
WindowProc called for window=00020C12 msg=WM_GETMINMAXINFO wparam=00000000 lparam=040AF69C WindowProc called for window=00020C12 msg=WM_NCCREATE wparam=00000000 lparam=040AF690 WindowProc called for window=00020C12 msg=WM_NCCALCSIZE wparam=00000000 lparam=040AF67C WindowProc called for window=00020C12 msg=WM_CREATE wparam=00000000 lparam=040AF690 WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 #WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 ##WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 ###WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 ####WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 #####WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 ######WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 #######WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000 ########WindowProc called for window=00020C12 msg=WM_SETFONT wparam=E60A1591 lparam=00000000

That just continues until you kill the program. Any ideas?

Henry

Does it happen on all windows versions i.e. windows 10, windows 7 etc?

I myself experience different behaviour in setting a control's parent under windows 10 and windows 7.
In Windows 10, it takes 10 seconds to create children controls within a TFrame's constructor if its parent is already set. No problem in windows 7.
Eventually, I only create the children controls before setting the TFrame's parent.

If your problem only appear in windows 10, maybe the parent property is where you should look at.

Dennis

It happens to all the computers in one organisation (win10), nowhere else that I know of. My first thought was something like anti-virus, but It's only our program that behaves badly, which is why I suspect a bug in the win32 lcl interface. We have many installs from XP up to 10 and I've never had any issues like this.

That's very interesting, thanks. We do create frames as part of the main form constructor and we set the parent first. Perhaps I should even delay that to when the form is shown.

Henry