Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
0.4.13-dev-618-ge4898e6 https://github.com/reactos/reactos/commit/e4898e6e0bd9517233c25f8f862e5a0ae9dce2f1
Description
I noticed a very rare / random crash sometimes on the testbots when testing the releases/0.4.14 during the 2nd stage setup. When it happens, the bots would then timeout after the logging:
(base/services/w32time/w32time.c:192) Time Server is 'pool.ntp.org'.
|
Up to recently I had no known way to make it reproducible, but now I found out that I can make it happen reliably with a DPH enabled build when quickling activating "breakOnFirstChance" asap very early in 2nd stage setup:
The callstack looks like that:
(base/services/w32time/w32time.c:171) Entered SetTime.
|
(base/services/w32time/w32time.c:192) Time Server is 'pool.ntp.org'.
|
|
|
Entered debugger on first-chance exception (Exception Code: 0xc0000005) (Page Fault)
|
Memory at 0x01F8D000 could not be read: Page not present.
|
kdb:> bt
|
Eip:
|
<ntdll.dll:2a84a (sdk/lib/rtl/unicode.c:569 (RtlInitAnsiString))>
|
Frames:
|
<ntdll.dll:2c4f5 (sdk/lib/rtl/unicode.c:2325 (RtlCreateUnicodeStringFromAsciiz))>
|
<advapi32.dll:850a (dll/win32/advapi32/reg/reg.c:3346 (RegOpenKeyExA))>
|
<ws2_32.dll:3926 (dll/win32/ws2_32/src/dcatalog.c:74 (WsTcOpen))>
|
<ws2_32.dll:42b0 (dll/win32/ws2_32/src/dcatalog.c:213 (WsTcInitializeFromRegistry))>
|
<ws2_32.dll:4933 (dll/win32/ws2_32/src/dprocess.c:43 (WsProcInitialize))>
|
<ws2_32.dll:4a84 (dll/win32/ws2_32/src/dprocess.c:137 (WsProcStartup))>
|
<ws2_32.dll:d9ed (dll/win32/ws2_32/src/startup.c:216 (WSAStartup))>
|
<w32time.dll:181d (base/services/w32time/ntpclient.c:32 (InitConnection))>
|
<w32time.dll:1a49 (base/services/w32time/ntpclient.c:163 (GetServerTime))>
|
<w32time.dll:1391 (base/services/w32time/w32time.c:201 (SetTime))>
|
<w32time.dll:1611 (base/services/w32time/w32time.c:285 (W32TmServiceMain))>
|
<svchost.exe:3858 (base/services/svchost/svchost.c:1152 (ServiceStarter))>
|
<advapi32.dll:1bde1 (dll/win32/advapi32/service/sctrl.c:210 (ScServiceMainStubW))>
|
<kernel32.dll:1c58c (dll/win32/kernel32/client/thread.c:70 (BaseThreadStartup))>
|
kdb:> cont
|
WARNING: RtlUnhandledExceptionFilter at sdk/lib/rtl/exception.c:309 is UNIMPLEMENTED!
|
Unhandled exception
|
ExceptionCode: c0000005
|
Faulting Address: 1f8d000
|
CS:EIP 1b:7c94a84a
|
DS 23 ES 23 FS 38 GS 0
|
EAX: 00000000 EBX: 01f8d000 ECX: ffffffff
|
EDX: 01327b94 EBP: 01327b7c ESI: 01f8d000 ESP: 01327b74
|
EDI: 01f8d000 EFLAGS: 00010206
|
Address:
|
0+7c94a84a
|
Frames:
|
0+7c94c4fa
|
0+7c41850f
|
0+7c1d392b
|
0+7c1d42b5
|
0+7c1d4938
|
0+7c1d4a89
|
0+7c1dd9f2
|
0+72121822
|
0+72121a4e
|
0+72121396
|
0+72121616
|
0+40385d
|
0+7c42bde6
|
0+7c5cc591
|
0.4.14-release-66-gc819d4a_DPH_timesrv_2ndStage_crash.log
I cannot say exactly whether it does still affect the current master head of 0.4.15-dev-5927-gbfc6a11 or not, because system-wide-DPH runs cannot be enabled anymore with master head due to CORE-12020.
But if anyone would remember which commit did fix this bug then please let me know!
I would also value a fingerpointing towards the commit which introduced the online-timesyncing within master-head to judge which release-branches are in need of the fix. I can definitely say that 0.4.7-release-234-gdc95ee3 was not affected yet by that kind of crash (because it did not have the time-syncing in 2nd stage yet).
Attachments
Issue Links
- blocks
-
-
- Resolved
-
- is blocked by
-
-
- Resolved
-