[Lazarus] Windows startup infinite loop

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lazarus] Windows startup infinite loop

Free Pascal - Lazarus mailing list
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
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Windows startup infinite loop

Free Pascal - Lazarus mailing list
On Wed, Feb 13, 2019 at 05:37:10PM +0000, Henry Vermaak wrote:

> 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?

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
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Windows startup infinite loop

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list


Henry Vermaak via lazarus wrote:
> 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:
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
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Windows startup infinite loop

Free Pascal - Lazarus mailing list
On Sat, 16 Feb 2019 at 07:06, Dennis via lazarus
<[hidden email]> wrote:

> Henry Vermaak via lazarus wrote:
> > 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:
> Does it happen on all windows versions i.e. windows 10, windows 7 etc?

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.

> 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.

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
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus