Details
-
Bug
-
Resolution: Unresolved
-
Trivial
-
None
-
None
-
None
Description
reactOS gcc dbg build, VBox 4.3.40, without VBox additions.
AC97 was installed and working but is not required to see this.
With 0.4.9-dev-709-g953dc72 aka "Dropping the VACB lock" the running-thread-count increased unexpectedly.
Looking at those code-changes does not imply that this is a sane outcome.
Eventually the "new threads" were existing also before and would have properly terminated then. And now hang with 0.4.9-dev-709 and newer builds.
The snapshots were done after 4th stage bootup.
In the past 3years the reported thread-count in taskmgr worked rather reliable for thousands of tries and never gave a delta > 1 thread. The change is significant.
The reported thread-counts of our taskmgr and the 2k3taskmgr are identical.
ros-build | thread# | Handle# | process# | commit comment |
---|---|---|---|---|
0.4.9-dev-710-gfd3a6c1 | 115 | 1112 | 17 | [NTOSKRNL] Properly reset VACB on free |
0.4.9-dev-709-g953dc72 | 115 | 1112 | 17 | [NTOSKRNL] Drop the VACB lock |
0.4.9-dev-708-g40017a5 | 109 | 1069 | 17 | [NTOSKRNL] Use interlocked operations... |
0.4.9-dev-705-gb54e5c6 | 108 | 1063 | 17 | [NTOS:MM] Do not map two pages... ThFabba |
Taskmgr shows that the unexpected threads do run within the processes eventlog.exe (+5) and services.exe (+2).
Compare 708a.png to 709a.png
and 708.png to 709.png
I doubt those will help, but here are also logs of bootup in 708.log and 709.log
Ged noted that within an MSVC+WinDbg build the command "!stacks" might help to dump the running threads.
-------
Side-note: Handle-count also increased significantly by the same commit. Significantly means here that it exceeds the usual random fluctuation of reported handle-count +-10 that is known for ros since years. I suspect significant part to vanish as well when we fix the thread-count.
-------
Attachments
Issue Links
- relates to
-
CORE-14349 Deadlocks can happen in Cc
- Resolved