Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-10267

Assertion failure 'PushLock->Waiting || PushLock->Shared == 0' on testbot

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: 0.4.0
    • Component/s: NTCore
    • Labels:
      None

      Description

      https://build.reactos.org/builders/Test%20VBox/builds/2500/steps/test/logs/stdio

      Running Wine Test, Module: kmtest, Test: MmMdl
       
      *** Assertion failed: PushLock->Waiting || PushLock->Shared == 0
      ***   Source File: /srv/buildbot/Build_GCCLin_x86/build/ntoskrnl/include/internal/ex.h, line 1176
       
      Break repeatedly, break Once, Ignore, terminate Process or terminate Thread (boipt)? 
      kdb:>
       o
      Execute '.cxr F71238B8' to dump context
      
      Entered debugger on embedded INT3 at 0x0008:0x8094ab42.
      kdb:>
       bt
      Eip:
      <NTOSKRNL.EXE:14ab43 (:0 (DbgBreakPoint))>
      Frames:
      <NTOSKRNL.EXE:3787b (ntoskrnl/include/internal/ex.h:1176 (ExRemoveHandleTable))>
      <NTOSKRNL.EXE:379bf (ntoskrnl/ex/handle.c:929 (ExDestroyHandleTable))>
      <NTOSKRNL.EXE:f9012 (ntoskrnl/ob/obhandle.c:2124 (ObKillProcess))>
      <NTOSKRNL.EXE:10d9a4 (ntoskrnl/ps/kill.c:837 (PspExitThread))>
      <NTOSKRNL.EXE:10df37 (ntoskrnl/ps/kill.c:940 (PsExitSpecialApc))>
      <NTOSKRNL.EXE:8a7ea (ntoskrnl/ke/apc.c:474 (KiDeliverApc))>
      <NTOSKRNL.EXE:131e97 (ntoskrnl/include/internal/i386/ke.h:776 (KiServiceExit2))>
      <NTOSKRNL.EXE:13070e (ntoskrnl/ke/i386/thrdini.c:84 (KiThreadStartup))>
      <NTOSKRNL.EXE:119951 (ntoskrnl/ps/thread.c:168 (PspSystemThreadStartup))>
      <ffffffff>
      <NTOSKRNL.EXE:97999 (ntoskrnl/ke/wait.c:367 (KeDelayExecutionThread))>
      <NTOSKRNL.EXE:98d09 (ntoskrnl/ke/wait.c:905 (NtDelayExecution))>
      <NTOSKRNL.EXE:1345d4 (ntoskrnl/include/internal/i386/ke.h:706 (KiSystemServiceHandler))>
      <NTOSKRNL.EXE:3da5 (:0 (KiFastCallEntry))>
      <ntdll.dll:c7ed>
      Couldn't access memory at 0x0161FF08!
      kdb:>

      I've only seen this the one time. But that assert obviously doesn't access the push lock atomically so the value can change between the checks for the two conditions.

        Attachments

          Activity

            People

            • Assignee:
              ThFabba ThFabba
              Reporter:
              ThFabba ThFabba
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: