[ros-dev] [ros-diffs] [jimtabor] 37223: - Fix WidenPath. Now Area.exe runs and crashes when using real hardware. That is a good thing. We now know our Xorg based region code has problems. It allocates all the memory building PolyPolygon region da

[James Tabor]

Hi,
LOL, Wine code does not work at all.... I tested Area.exe with the
latest head and it dies and the application continues to work with out
drawing the PATH figures.

ReactOS:

(subsystems/win32/win32k/objects/gdiobj.c:544) Object->cExclusiveLock = 1
(subsystems/win32/win32k/objects/path.c:1911) BeginPath 1 0xbc07024b
(subsystems/win32/win32k/objects/path.c:1936) BeginPath 2 h 0xbd07024b
p 0x8d9b4830
(subsystems/win32/win32k/objects/path.c:2022) EndPath 0xbd07024b
(ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 8192 bytes from paged
pool - nothing suitable found, returning NULL
(subsystems/win32/win32k/objects/path.c:1609) Should never happen
(subsystems/win32/win32k/objects/path.c:1609) Should never happen
(subsystems/win32/win32k/objects/path.c:1609) Should never happen
(subsystems/win32/win32k/objects/path.c:1609) Should never happen
(subsystems/win32/win32k/objects/path.c:1609) Should never happen
(subsystems/win32/win32k/objects/path.c:1612) Got path flag
(ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 4096 bytes from paged
pool - nothing suitable found, returning NULL

<snip>

(ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 11264 bytes from paged
pool - nothing suitable found, returning NULL
(subsystems/win32/win32k/objects/gdiobj.c:544) Object->cExclusiveLock = 1
(subsystems/win32/win32k/objects/path.c:1911) BeginPath 1 0xbd07024b
(subsystems/win32/win32k/objects/path.c:1936) BeginPath 2 h 0xbe07024b
p 0x8d9b4830
(subsystems/win32/win32k/objects/path.c:2022) EndPath 0xbe07024b
(ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 2048 bytes from paged
pool - nothing suitable found, returning NULL

<snip>

(ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 2400 bytes from paged
pool - nothing suitable found, returning NULL
Entered debugger on last-chance exception (Exception Code: 0xc0000005)
(Page Fault)
Memory at 0x000004B0 could not be written: Page not present.
kdb:> bt
Eip:
<win32k.sys:84c9c (subsystems/win32/win32k/objects/bezier.c:160
(GDI_InternalBezier at 20))>
Frames:
<win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178
(GDI_InternalBezier at 20))>
<win32k.sys:85008 (subsystems/win32/win32k/objects/bezier.c:216
(@GDI_Bezier at 12))>
<win32k.sys:a1760 (subsystems/win32/win32k/objects/path.c:988
(@PATH_AddFlatBezier at 12))>
<win32k.sys:a286a (subsystems/win32/win32k/objects/path.c:1019
(@PATH_FlattenPath at 4))>
<win32k.sys:a295e (subsystems/win32/win32k/objects/path.c:1514
(NtGdiWidenPath at 4))>
<NTOSKRNL.EXE:a145a (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5f1e>
<Area.exe:35ad>
<04ec8353>
Couldn't access memory at 0x56E58959!
kdb:>

The problem is in IntCreatePolyPolygonRgn, it is based on Xorg
mipolygen.c. The figure is some what complex and this old Xorg code
seems to become over whelmed by it.  IntCreatePolyPolygonRgn calles
REGION_InsertionSort hundreds or even thousands of times. Using Qemu
you will sit there all night and that is the reason for using hardware
for this test. The first figure was 3 polygons with a total of 516
points. Question is, why is that so hard to map and sort? I assume the
next three figures have the same or close to the same amount of
points. Since they do look and draw about the same.

The bug report has GDI_InternalBezier faulting out the kernel, well
since there is no more PagedPool available so it returned a NULL
without faulting.

I'm looking into alternative methods that are much simpler than the
Xorg code for mapping and filling regions. My best one is from
Graphapp, it is a modified variation of the same Xorgs poly code. This
means more time I do not have to work out a hypothesise and rewrite
all of the region code.

FYI: Our Xorg code is the same Xorg code that is in wine....... I
assume wine code breaks and bombs out when the memory pool empties.
Which is not avalid excuse not to draw.

Thanks,
James

On Thu, Nov 6, 2008 at 7:05 AM, Aleksey Bragin <aleksey at reactos.org> wrote:
> How does this code work in Wine without this change?
>
> WBR,
> Aleksey.
>