Discussion:
MinTTY requires gdiplus.dll ? (2)
(too old to reply)
Houder
2018-11-29 18:41:56 UTC
Permalink
Hi,

As I wrote in the preceding post ...

Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.

Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty )

Placing strace in front of this call, results in:

64-@@ strace /usr/bin/mintty
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at
00000000777b0000
--- Process 3112 loaded C:\Windows\System32\kernel32.dll at
0000000077690000
--- Process 3112 loaded C:\Windows\System32\KernelBase.dll at
000007fefd490000
--- Process 3112 loaded E:\Cygwin64\bin\cygwin1.dll at 0000000180040000
--- Process 3112 loaded C:\Windows\System32\advapi32.dll at
000007fefd750000
--- Process 3112 loaded C:\Windows\System32\msvcrt.dll at
000007feff0a0000
--- Process 3112 loaded C:\Windows\System32\sechost.dll at
000007feff910000
--- Process 3112 loaded C:\Windows\System32\rpcrt4.dll at
000007feff630000
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at
000007fefdc10000
--- Process 3112 loaded C:\Windows\System32\user32.dll at
0000000077590000
--- Process 3112 loaded C:\Windows\System32\lpk.dll at 000007feff3a0000
--- Process 3112 loaded C:\Windows\System32\usp10.dll at
000007feff9d0000
--- Process 3112 loaded C:\Windows\System32\shlwapi.dll at
000007feff140000
--- Process 3112 loaded C:\Windows\System32\comdlg32.dll at
000007fefefa0000
--- Process 3112 loaded C:\Windows\System32\shell32.dll at
000007fefe130000
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
--- Process 3112 loaded C:\Windows\System32\ole32.dll at
000007feff3b0000
--- Process 3112 loaded C:\Windows\System32\imm32.dll at
000007fefd720000
--- Process 3112 loaded C:\Windows\System32\msctf.dll at
000007fefdb00000
--- Process 3112 loaded C:\Windows\System32\winmm.dll at
000007fefa040000
--- Process 3112 loaded C:\Windows\System32\winspool.drv at
000007fef9f10000
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
64-@@ uname -a
CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin
64-@@

For the expert among us ...

=====

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Corinna Vinschen
2018-11-29 19:58:45 UTC
Permalink
Post by Houder
Hi,
As I wrote in the preceding post ...
Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at 00000000777b0000
--- Process 3112 loaded C:\Windows\System32\kernel32.dll at 0000000077690000
--- Process 3112 loaded C:\Windows\System32\KernelBase.dll at
000007fefd490000
--- Process 3112 loaded E:\Cygwin64\bin\cygwin1.dll at 0000000180040000
--- Process 3112 loaded C:\Windows\System32\advapi32.dll at 000007fefd750000
--- Process 3112 loaded C:\Windows\System32\msvcrt.dll at 000007feff0a0000
--- Process 3112 loaded C:\Windows\System32\sechost.dll at 000007feff910000
--- Process 3112 loaded C:\Windows\System32\rpcrt4.dll at 000007feff630000
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at 000007fefdc10000
--- Process 3112 loaded C:\Windows\System32\user32.dll at 0000000077590000
--- Process 3112 loaded C:\Windows\System32\lpk.dll at 000007feff3a0000
--- Process 3112 loaded C:\Windows\System32\usp10.dll at 000007feff9d0000
--- Process 3112 loaded C:\Windows\System32\shlwapi.dll at 000007feff140000
--- Process 3112 loaded C:\Windows\System32\comdlg32.dll at 000007fefefa0000
--- Process 3112 loaded C:\Windows\System32\shell32.dll at 000007fefe130000
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
--- Process 3112 loaded C:\Windows\System32\ole32.dll at 000007feff3b0000
--- Process 3112 loaded C:\Windows\System32\imm32.dll at 000007fefd720000
--- Process 3112 loaded C:\Windows\System32\msctf.dll at 000007fefdb00000
--- Process 3112 loaded C:\Windows\System32\winmm.dll at 000007fefa040000
--- Process 3112 loaded C:\Windows\System32\winspool.drv at 000007fef9f10000
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.

It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS window, the problem
disappears.

Worse, the problem also disappears when running mintty under gdb.


Corinna
--
Corinna Vinschen
Cygwin Maintainer
Thomas Wolff
2018-11-29 22:11:31 UTC
Permalink
Post by Corinna Vinschen
Post by Houder
Hi,
As I wrote in the preceding post ...
Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at 00000000777b0000
...
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at 000007fefdc10000
...
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
...
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
There's also another dll reported from winsxs rather than System32 in
your log. Maybe some files got corrupted on your system?
Post by Corinna Vinschen
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
Unclear to me what exactly can be reproduced. With today's snapshot
cygwin1.dll, I can start mintty any way, also from Explorer, via
shortcut, or directly from cmd.exe (skipping cygwin shell).
Thomas
Post by Corinna Vinschen
It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS window, the problem
disappears.
Worse, the problem also disappears when running mintty under gdb.
Corinna
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Houder
2018-11-29 22:40:46 UTC
Permalink
[snip]
Post by Thomas Wolff
Post by Houder
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at
00000000777b0000
...
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at
000007fefdc10000
...
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
...
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
There's also another dll reported from winsxs rather than System32 in
your log. Maybe some files got corrupted on your system?
Files corrupted on Windows? Very likely.

That is why I stay as much as is possible way from my C:\ drive (in any
form or
manner) ...

And you are right (GdiPlus.dll) ... I missed that. Now that I know how
the name
must be spelled:

64-@@# find /drv/c/Windows -type f -name GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.17514_none_3bd2e487d8e769d3/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_2b24536c71ed437a/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.17514_none_83801b5eed6392d9/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.18946_none_8382f002ed61108b/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24234_none_2507449df28cf2b8/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23407_none_2503fd39f28ff711/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.18946_none_3bd5b92bd8e4e785/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23149_none_5c0676f9a00e9169/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24280_none_6cb9d807070433ed/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18946_none_2b27281071eac12c/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24280_none_250ca12ff2880ae7/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23149_none_2507d13df28c8ebc/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_5c0b46eba00a0d94/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23407_none_14556c1e8b95d0b8/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23407_none_6cb13411070c2017/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23149_none_6cb508150708b7c2/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18946_none_72d45ee78666ea32/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23407_none_5c02a2f5a011f9be/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23149_none_145940228b926863/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24234_none_5c05ea59a00ef565/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24234_none_1458b3828b92cc5f/GdiPlus.dll
/drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e/GdiPlus.dll
/drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24234_none_6cb47b7507091bbe/GdiPlus.dll

Lot of them!

Now I have to find out ... how to select the proper one and put it back
in its proper
place.

... and I do not even want to know why it got lost :-(

Regards,

Henri

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Houder
2018-11-29 23:34:58 UTC
Permalink
[snip]
Post by Thomas Wolff
Post by Houder
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at
00000000777b0000
...
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at
000007fefdc10000
...
--- Process 3112 loaded
C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
...
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
There's also another dll reported from winsxs rather than System32 in
your log. Maybe some files got corrupted on your system?
Right.

copied this one:
c:/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e/GdiPlus.dll
( 2177536 Oct 6 17:58 )

to c:/Windows/system32, on the 64-bits instance of Cygwin, and

copied this one:
c:/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_5c0b46eba00a0d94/GdiPlus.dll
( 1633280 Oct 6 17:43 )

to c:/Windows/system32, on the 32-bits instance of Cygwin.

(and No, normally I do not do these kinds of things. I think Windows
should take
care of itself -- it does not)

Now, "cygcheck mintty" (both on 64-bits and 32-bits) is "happy": all
DLL's can be
found ... Good Heavens.

Henri

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Corinna Vinschen
2018-11-30 12:17:23 UTC
Permalink
Post by Corinna Vinschen
Post by Houder
Hi,
As I wrote in the preceding post ...
Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at 00000000777b0000
...
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc
tl32.dll at 000007fefb9c0000
--- Process 3112 loaded C:\Windows\System32\gdi32.dll at 000007fefdc10000
...
--- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll
at 000007fefb440000
...
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
There's also another dll reported from winsxs rather than System32 in your
log. Maybe some files got corrupted on your system?
Post by Corinna Vinschen
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
Unclear to me what exactly can be reproduced. With today's snapshot
cygwin1.dll, I can start mintty any way, also from Explorer, via shortcut,
or directly from cmd.exe (skipping cygwin shell).
Thomas
Are you running Windows 10? If so, you won't see this problem.
It only occurs on pre-W10 systems. I have a local workaround but
I want to debug this a bit more since I still don't understand *why*
this occurs in the first place.

Btw., a mintty-debuginfo package would be most helpful...


Corinna
--
Corinna Vinschen
Cygwin Maintainer
Houder
2018-11-30 12:42:24 UTC
Permalink
[snip]
Post by Corinna Vinschen
Post by Houder
--- Process 3112 loaded C:\Windows\System32\winmm.dll at
000007fefa040000
--- Process 3112 loaded C:\Windows\System32\winspool.drv at
000007fef9f10000
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS window, the problem
disappears.
Worse, the problem also disappears when running mintty under gdb.
(I do not understand _exactly_ what you say here)

Uhm, if I invoke "gdb /usr/bin/mintty" (so, from the "Dos box") the
problem
does NOT disappear.

That is:

2 threads are created ... and that is it; no MinTTY window showing
up!

(hint: my system is a bit more peculiar than yours)

Henri

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Corinna Vinschen
2018-11-30 13:19:18 UTC
Permalink
Post by Houder
[snip]
Post by Corinna Vinschen
Post by Houder
--- Process 3112 loaded C:\Windows\System32\winmm.dll at
000007fefa040000
--- Process 3112 loaded C:\Windows\System32\winspool.drv at 000007fef9f10000
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS window, the problem
disappears.
Worse, the problem also disappears when running mintty under gdb.
(I do not understand _exactly_ what you say here)
Uhm, if I invoke "gdb /usr/bin/mintty" (so, from the "Dos box") the problem
does NOT disappear.
2 threads are created ... and that is it; no MinTTY window showing up!
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes. If you find out why, I'd be
most grateful.


Corinna
--
Corinna Vinschen
Cygwin Maintainer
Houder
2018-11-30 14:05:56 UTC
Permalink
Post by Corinna Vinschen
Post by Houder
[snip]
Post by Corinna Vinschen
Post by Houder
--- Process 3112 loaded C:\Windows\System32\winmm.dll at
000007fefa040000
--- Process 3112 loaded C:\Windows\System32\winspool.drv at 000007fef9f10000
--- Process 3112, exception c0000005 at 0000000180044bb3
--- Process 3112 exited with status 0xc0000005
Segmentation fault
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS window, the problem
disappears.
Worse, the problem also disappears when running mintty under gdb.
(I do not understand _exactly_ what you say here)
Uhm, if I invoke "gdb /usr/bin/mintty" (so, from the "Dos box") the problem
does NOT disappear.
2 threads are created ... and that is it; no MinTTY window showing up!
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes. If you find out why, I'd be
most grateful.
Sorry Corinna, your request is way over my head. I can only confirm,
that gdb
does not return in clock.c

I set a breakpoint as you instructed. Subsequently I entered "run":

Thread 1 hit Breakpoint 1, clk_monotonic_t::now (
this=***@entry=0x1802f91b0
<strace::microseconds()::clock_monotonic>,
clockid=***@entry=0, ts=***@entry=0xffffc7c0)
at
/ext/build/mknetrel/src/cygwin-snapshot-20181129-1/winsup/cygwin/clock.cc

Then I "stepped" through winsup/cygwin/clock.cc

169 in
/ext/build/mknetrel/src/cygwin-snapshot-20181129-1/winsup/cygwin/cloc
k.cc
(gdb)

Here "I lost control" ...

Using https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git, I can
see that
it is "close" to the call of init() in clk_monotonic_t::now().

That is it for the moment. Still curious what Thomas W. has to report
about his
system.

Regards,

Henri

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Houder
2018-12-01 08:57:15 UTC
Permalink
On 2018-11-30 14:19, Corinna Vinschen wrote:
[snip]
Post by Corinna Vinschen
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes. If you find out why, I'd be
most grateful.
Below I included parts of the diff between 1126 and 1129. You have been
refactoring the code related to "timing".

Above you state that the call to init() (clk_monotonic_t::init(), is my
understanding) from clk_monotonic_t::now() makes the cygwin1.dll end up
in "some mysterious loop" (my wording). At least on pre-W10 ...

Looking at the code (trying to understand it), it appears to me that it
is NOT "Windows version" dependent ...

My question: why do you claim in

https://cygwin.com/ml/cygwin/2018-11/msg00261.html

that Windows 10 is NOT affected? Does W10 run a different "thread" in
the Cygwin codebase?

Regards,
Henri

======
https://cygwin.com/snapshots/x86/cygwin-diffs-20181126-20181129

FILE: winsup/cygwin/clock.h:

+class clk_t
+{
+ protected:
+ LONG inited;
+ LONGLONG ticks_per_sec;
+ virtual void init ();
+ virtual int now (clockid_t, struct timespec *) = 0
...

+class clk_monotonic_t : public clk_t
+{
+ protected:
+ virtual void init ();
+ private:
+ virtual int now (clockid_t, struct timespec *);
+};
...

FILE: winsup/cygwin/clock.cc:

+void
+clk_t::init ()
+{
+ spinlock spin (inited, 1);
+ if (!spin)
+ ticks_per_sec = system_tickcount_resolution ();
+}
+
...

+void
+clk_monotonic_t::init ()
+{
+ spinlock spin (inited, 1);
+ if (!spin)
+ ticks_per_sec = system_qpc_resolution ();
+}
...

+int
+clk_monotonic_t::now (clockid_t clockid, struct timespec *ts)
+{
+ if (wincap.has_precise_interrupt_time ())
+ {
+ /* Suspend time not taken into account, as on Linux */
+ ULONGLONG now;
+
+ QueryUnbiasedInterruptTimePrecise (&now);
+ ts->tv_sec = now / NS100PERSEC;
+ now %= NS100PERSEC;
+ ts->tv_nsec = now * (NSPERSEC/NS100PERSEC);
+ }
+ else
+ {
+ /* https://stackoverflow.com/questions/24330496. Skip rounding
since
+ its almost always wrong when working with timestamps */
+ UINT64 bias;
+ LARGE_INTEGER now;
+ struct timespec bts;
+
+ if (inited <= 0)
+ init (); // Henri: invocation of
clk_monotonic_t::init()
+ do
+ {
+ bias = SharedUserData.InterruptTimeBias;
+ QueryPerformanceCounter(&now);
+ }
+ while (bias != SharedUserData.InterruptTimeBias);
+ /* Convert perf counter to timespec */
+ ts->tv_sec = now.QuadPart / ticks_per_sec;
+ now.QuadPart %= ticks_per_sec;
+ ts->tv_nsec = (now.QuadPart * NSPERSEC) / ticks_per_sec;
+ /* Convert bias to timespec */
+ bts.tv_sec = bias / NS100PERSEC;
+ bias %= NS100PERSEC;
+ bts.tv_nsec = bias * (NSPERSEC/NS100PERSEC);
+ /* Subtract bias from perf */
+ ts_diff (bts, *ts);
+ }
+ return 0;
+}

=====

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Corinna Vinschen
2018-12-01 09:48:53 UTC
Permalink
Post by Houder
[snip]
Post by Corinna Vinschen
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes. If you find out why, I'd be
most grateful.
Below I included parts of the diff between 1126 and 1129. You have been
refactoring the code related to "timing".
Above you state that the call to init() (clk_monotonic_t::init(), is my
understanding) from clk_monotonic_t::now() makes the cygwin1.dll end up
in "some mysterious loop" (my wording). At least on pre-W10 ...
Looking at the code (trying to understand it), it appears to me that it
is NOT "Windows version" dependent ...
My question: why do you claim in
https://cygwin.com/ml/cygwin/2018-11/msg00261.html
that Windows 10 is NOT affected? Does W10 run a different "thread" in
the Cygwin codebase?
On W10, wincap.has_precise_interrupt_time () is true.


Corinna
--
Corinna Vinschen
Cygwin Maintainer
Loading...