Summary: | American Conquest via Wine cannot start | ||
---|---|---|---|
Product: | Mesa | Reporter: | almos <aaalmosss> |
Component: | Mesa core | Assignee: | mesa-dev |
Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | ||
Version: | 18.2 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
memap_ac.png
memmap_cossacks.png |
Description
almos
2017-07-26 14:37:53 UTC
Just sharing some ideas, I likely won't be able to help much. Possible issues include: - file is not there, has wrong permissions, is corrupted - map fails due to wrong permissions of the segment, OOM conditions strace should help narrowing it down. There is nothing wrong with libLLVM-4.0.so.1 as far as I can tell. Only American Conquest throws this error, so there must be something special about this one exe. I compiled Mesa without LLVM, so I could try it with softpipe. I get no dlopen error, but the X error remains. Here is what I have managed to debug so far: - Wine creates a GLX context to query the OpenGL information, destroys it, and creates a permanent one for GDI drawing; the error happens for the second one - In softpipe_create_context() the CALLOC_STRUCT() fails for sp_create_tex_tile_cache() (always at sh=4 and i=28...30), I have no idea why - In CreateContext() (mesa/src/glx/glxcmds.c:278) psc->vtable->create_context() fails because of the previous point, and indirect_create_context() is attempted - The X server rejects indirect contexts (xserver/glx/glxcmds.c:284), hence the X error The hard part is that gdb doesn't work on Wine, and winedbg is mostly useless. Sounds to me like you're simply running out of (virtual) memory. Those allocations in softpipe are quite a waste of memory, albeit not THAT big (each tile is 32x32 pixels, at 16 bytes, so 16kB, and there's 16 tiles per shader type and per sampler view - with 6 shader types and 32 sampler views that adds up to (typically mostly never used...) 48MB. That's probably also the reason why the map fails with radeonsi. I have no idea though where all your virtual memory address space went, but I don't see any evidence it's really related to mesa, albeit there recently was a new and already fixed memory leak. I ran wine with strace, gathered the relevant syscalls (mmap, mmap2, munmap), and wrote a program to visualize the memory usage: the 1024x1024 pixels each represent a 4096 byte page, black is unallocated, green is allocated with position hint, blue is allocated with NULL hint, yellow is unmapped. I'll attach the results for American Conquest (up until the failed mmap for libLLVM.so), and Cossacks European Wars (I killed it when the main menu appeared). There are plenty of free space left in both cases. Can this be a glitch in the kernel's memory allocator? How can I debug that? Created attachment 133581 [details]
memap_ac.png
Created attachment 133582 [details]
memmap_cossacks.png
On i965 I get: XIO: fatal IO error 12 (Cannot allocate memory) on X server ":0" after 273 requests (273 known processed) with 0 events remaining. I suspect this is a wine or game bug but for now reassigning to Mesa Core. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1014. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.