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

Regression: reproducible bugcheck BAD_POOL_CALLER during SoundCloud playback in KMeleon 76.5.4 Goanna engine

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • 0.4.15
    • Win32SS
    • Oracle VM VirtualBox 7.0.15.

    Description

      Steps to reproduce:

      1. Download KMeleon Goanna 76.5.4 here: https://o.rthost.win/kmeleon/KM76.5.4-Goanna-20240629.7z.
      2. Extract it from the archive.
      3. Run kmeleon.exe.
      4. open soundcloud.com by entering it in the URL bar and pressing Enter. (I also logined into my account, but I don't think it affect the issue in any way).
      5. After opening, try to play a random track.
      6. When it plays, try to play another random track.

      It did not occur before, up to 0.4.15-dev-8252-gf28e983, commit https://github.com/reactos/reactos/commit/f28e983932131b2aded07bb11371db22ccb05b04. It worked as expected.

      But starting from 0.4.15-dev-8253-g0f9e889, commit https://github.com/reactos/reactos/commit/0f9e889736f01cef58fd50cd1f5558becbe882d5, doing the last step results in BSOD 0xC2 BAD_POOL_CALLER with the following stack trace:

      *** Fatal System Error: 0x000000c2
                             (0x00000042,0x00000000,0x00000000,0x00000000)
      Entered debugger on embedded INT3 at 0x0008:0x805AB3AC.kdb:> bt
      [?7hEip:
      <ntoskrnl.exe:1ab3ac (sdk/lib/rtl/i386/debug_asm.S:56 (RtlpBreakWithStatusInstruction))>
      Frames:
      <ntoskrnl.exe:97dcd (ntoskrnl/ke/bug.c:1067 (KeBugCheckWithTf))>
      <ntoskrnl.exe:98337 (ntoskrnl/ke/bug.c:1416 (KeBugCheckEx))>
      <ntoskrnl.exe:cec8d (ntoskrnl/mm/ARM3/pool.c:417 (MmDeterminePoolType))>
      <ntoskrnl.exe:bb0b0 (ntoskrnl/mm/ARM3/expool.c:2587 (ExFreePoolWithTag))>
      <win32k.sys:c4e11 (win32ss/gdi/ntgdi/freetype.c:223 (FontLink_Chain_Free))>
      <win32k.sys:ce73e (win32ss/gdi/ntgdi/freetype.c:250 (TextIntGetTextExtentPoint))>
      <win32k.sys:f06cb (win32ss/gdi/ntgdi/text.c:417 (NtGdiGetTextExtentExW))>
      <ntoskrnl.exe:3fe5 (:0 (KiSystemCallTrampoline))>
      <ntoskrnl.exe:168bb1 (ntoskrnl/ke/i386/traphdlr.c:1840 (KiSystemServiceHandler))>
      <ntoskrnl.exe:3e2f (:0 (KiFastCallEntry))>
      <ntdll.dll:f8ad>
      <lpk.dll:34fa>
      <gdi32.dll:18dff>
      <user32.dll:6a977>
      <user32.dll:4e812>
      <comctl32.dll:92154>
      <comctl32.dll:96219>
      <comctl32.dll:96913>
      <user32.dll:6b871>
      <user32.dll:5fb67>
      <user32.dll:60111>--- Press q to abort, any other key to continue ---<mfc120u.dll:239a1a>
      <mfc120u.dll:23903f>
      <mfc120u.dll:23a970>
      <mfc120u.dll:1b29e2>
      <mfc120u.dll:238fa3>
      <mfc120u.dll:2391c5>
      <mfc120u.dll:137ef9>
      <user32.dll:6b871>
      <user32.dll:5fb67>
      <user32.dll:619ae>
      <ntdll.dll:f800>
      <k-meleon.exe:2b39c>
      <mfc120u.dll:24be51>
      <k-meleon.exe:473fc>
      <kernel32.dll:11cd9>kdb:>  

      It actually fails on freeing the string buffer with a name of some linked font.

      The guilty commit is tested as well and it's obviously correct because it introduces the faulting code.

      And this bugcheck does not even mean a wrong pool tag. The 1st sub-code 0x42 means wrong pool type, which is failing to be determined properly.

      We're failing here: https://git.reactos.org/?p=reactos.git;a=blob;f=ntoskrnl/mm/ARM3/pool.c;hb=22561d5046ac9370746ba17f84379638ec542372#l417 appropriately in case the pool does not match a criteria to be detected as a paged or non-paged pool. My suggestion is try to switch to NonPagedPool in the FreeType code: https://git.reactos.org/?p=reactos.git;a=blob;f=win32ss/gdi/ntgdi/freetype.c;h=a243f01523b4516b5ab688735e7c22e163388b47;hb=d4433ee0c9ba8ad78dc91e9ba17a408ed5c739e6#l1360, and if that does not help, then try to fix the pool itself. Or, alternatively, we should relax the criteria for allocating that pool here: https://git.reactos.org/?p=reactos.git;a=blob;f=win32ss/gdi/ntgdi/freetype.c;h=a243f01523b4516b5ab688735e7c22e163388b47;hb=d4433ee0c9ba8ad78dc91e9ba17a408ed5c739e6#l1354, because it isn't allocated in case of success. So in this case, the pool remains invalid and hence it fails to be freed. But I'm not sure about this yet, it's only my guessing. I may be wrong here.

      Attachments

        1. debug_2.log
          149 kB
        2. debug_dm.log
          67 kB
        3. debug.log
          102 kB
        4. font-link-bsod.png
          font-link-bsod.png
          161 kB

        Issue Links

          Activity

            People

              Oleg Dubinskij Oleg Dubinskiy
              Oleg Dubinskij Oleg Dubinskiy
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: