http://bugs.winehq.org/show_bug.cgi?id=13335
Summary: libGl error Product: Wine Version: unspecified Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: schuster.bernhard@googlemail.com
In the near past, whenever trying to run warcraft via wine, I get two libGL errors. Afterwards, I get told, that mesa will get used instead. So performence goes really bad. I get about 10-20fps instead of 120-160fps, though I have an insane gaming rig. The only way to fix it, is removing the ~/.wine directory completly. But that's not an real option...
http://bugs.winehq.org/show_bug.cgi?id=13335
Ben Hodgetts (Enverex) ben@atomnet.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ben@atomnet.co.uk Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #1 from Ben Hodgetts (Enverex) ben@atomnet.co.uk 2008-05-21 09:36:10 --- Please fill in all the fields in future. Your bug name is not helpful, you didn't specify what version of Wine either. Warcraft is a DOS game, use DOSBox. Also libGL errors are issues with your graphics card drivers, not Wine.
http://bugs.winehq.org/show_bug.cgi?id=13335
soxs schuster.bernhard@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Status|RESOLVED |UNCONFIRMED Resolution|INVALID | Version|unspecified |1.0-rc1
--- Comment #2 from soxs schuster.bernhard@googlemail.com 2008-05-21 09:41:00 --- It is exlcusivley a wine error, ET:QW runs fine, glxinfo confirms, that direct rendering is activated, fglrxinfo shows proper values for renderer. And I did not fill in all fields, because it affects differnent versions and simply do NOT know enough specific info what exactly causes this same bug.
http://bugs.winehq.org/show_bug.cgi?id=13335
soxs schuster.bernhard@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGl error |libGL error when launching | |warcraft 3
http://bugs.winehq.org/show_bug.cgi?id=13335
MGSX2 mgsx2@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mgsx2@hotmail.com
--- Comment #3 from MGSX2 mgsx2@hotmail.com 2008-05-21 09:48:23 --- With wine-1-rc1 and the most recent ATI catalyst drivers on Debian Sid x86_64 and an ATI X1800 XT card I keep getting this error when starting with opengl switch:
libGL error: drmMap of framebuffer failed (Nicht genügend Hauptspeicher verfügbar) libGL error: reverting to (slow) indirect rendering
Then WC3 starts but the graphics are corrupted and I have like 1 frame/second.
The drivers are correctly installed, Direct Rendering from glxinfo sais YES and other games in Wine like Counter Strike 1.6 using OpenGL run fine.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #4 from MGSX2 mgsx2@hotmail.com 2008-05-21 09:49:16 ---
The only way to fix it, is removing the ~/.wine directory completly. But that's not an real option...
I don't understand. Removing .wine and reinstalling wc3 fixed the problem for you?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #5 from MGSX2 mgsx2@hotmail.com 2008-05-21 09:57:38 --- I just removed .wine, did wineprefixcreate and reinstalled WC3 but it didn't help.
I let you know so you don't have to waste the time too ;)
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #6 from Austin English austinenglish@gmail.com 2008-05-21 11:02:25 --- (In reply to comment #1)
Warcraft is a DOS game, use DOSBox.
*Mildly off topic* Please don't tell users that Wine can't run DOS applications. We may not do it very well, and DOSBox can be used as a workaround, but not a solution.
/End rant
Have you filed a bug with ATI?
http://bugs.winehq.org/show_bug.cgi?id=13335
Nicolay Doytchev lightrush@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lightrush@gmail.com
--- Comment #7 from Nicolay Doytchev lightrush@gmail.com 2008-05-21 11:12:51 --- Try another driver. Try NVIDIA on the same rig. If the bug is still existent - do a regression testing. http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #8 from MGSX2 mgsx2@hotmail.com 2008-05-21 11:13:48 --- (In reply to comment #6)
Have you filed a bug with ATI?
Yes, they didn't respond yet.
Another guy filed a bug here:
http://ati.cchtml.com/show_bug.cgi?id=1109
but it seems that one can't watch another's bug requests so I wrote one too.
I'll let you know as soon as they respond, god willing.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #9 from MGSX2 mgsx2@hotmail.com 2008-05-21 11:15:25 --- (In reply to comment #7)
Try another driver. Try NVIDIA on the same rig. If the bug is still existent - do a regression testing. http://wiki.winehq.org/RegressionTesting
I had an NVidia card before and it worked fine. I remove all the NVidia drivers and tried several ATI drivers from 2007 and the new catalyst from 2008 together with wine-0.9.57, -59, -61 and 1-rc1. None worked.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #10 from Nicolay Doytchev lightrush@gmail.com 2008-05-21 11:42:52 --- You didnt give any info on your OS. I hope it is Ubuntu or Deb - here is a package - try this one and check if you r getting the same probs. http://www.mediafire.com/?tsdj6hym2mx
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #11 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-21 12:15:35 --- Starting from the most obvious - have you removed/disabled compiz? Are you making _any_ changes to Wine configuration (via winecfg, registry, etc)?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #12 from MGSX2 mgsx2@hotmail.com 2008-05-21 13:52:30 --- (In reply to comment #11)
Starting from the most obvious - have you removed/disabled compiz? Are you making _any_ changes to Wine configuration (via winecfg, registry, etc)?
No composite manager at all, I'm running a custom x86_64 kernel on Debian Sid x86_64. X and Window manager is plain Xorg with Openbox. I tried it with several kernel versions, no changes.
The same with wine installation, I tried it with the registry hacks required for warcraft 3, without them and then with a fresh wine installation.
To sum it up, I tried it with different wine versions (.57, .59, .61, 1-rc1), several kernel versions since 2.6.18 and different ATI driver versions since October 2007 until the most recent 8.4. None of them worked with WC3.
The occurence of this bug is definately not a wrong configuration. I tried it with Composite "Disable" and disabling of the AIGLX, no changes too.
The wine rc1 installation is patched with the two fixes for Battle.net access and taskswitching in X, the other wine versions I tried are unchanged and compiled from the source downloaded at winehq.org.
I should say again that this bug just came up when I swapped my NVidia card for an ATI, everything worked fine before and even now, other OpenGL programs run fine with the fglrx drivers, also under wine like counterstrike 1.6 which uses OpenGL extensively.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #13 from Nicolay Doytchev lightrush@gmail.com 2008-05-21 14:57:16 --- can u check it on 32bit debian?
http://bugs.winehq.org/show_bug.cgi?id=13335
Rich Rincebrain@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Rincebrain@gmail.com
--- Comment #14 from Rich Rincebrain@gmail.com 2008-05-22 05:15:37 --- Can you confirm that the same behavior happens if you pass WC3 the -opengl flag? (By default, it uses DirectX.)
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #15 from MGSX2 mgsx2@hotmail.com 2008-05-22 06:32:54 --- Yes, without -opengl it crashes before start. (also with ATI only).
Today I put in the NVidia again, removed ATI drivers, installed NVidia, and everything runs fine.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #16 from soxs schuster.bernhard@googlemail.com 2008-05-23 04:49:28 --- For anyone who will test ATI vs. NVIDIA, you should use the latest ati driver (8.5 atm)
I thought at least thtat removing the homedir had helped, but atm it seems to be, that it was 0.9.58 (selcompiled due to a lack of phenom support) which fixed that problem.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #17 from MGSX2 mgsx2@hotmail.com 2008-05-23 05:06:13 --- I reviewed the versions I tested:
0.9.57 0.9.59 0.9.60 0.9.61 1.0-rc1
which would mean that 0.9.58 is running but previous and later versions are not (?!)
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tony.wasserka@freenet.de
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #18 from Tony Wasserka tony.wasserka@freenet.de 2008-05-23 05:39:00 --- This problem affects me, too. I'm also using an ATI on fglrx 8.493 (8.5). However, as on the one hand this only happens on ATI cards and on the other one native UNIX apps work fine I think this should be marked as a showstopper for 1.0 until we either fixed it or know properly that it's ATI's fault.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #19 from Tony Wasserka tony.wasserka@freenet.de 2008-05-23 06:04:17 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #20 from Tony Wasserka tony.wasserka@freenet.de 2008-05-23 06:42:54 --- I just rebuilt Wine 0.9.58. That version doesn't fix it either, so the bug was introduced (or at least apparent) before 0.9.57. However, IIRC I rebuilt 0.9.44 once and this version had the bug, too, so the problem must be very old now... rebuilding 0.9.30, I hope this version is still able to run Warcraft :D
http://bugs.winehq.org/show_bug.cgi?id=13335
soxs schuster.bernhard@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schuster.bernhard@googlemail | |.com
--- Comment #21 from soxs schuster.bernhard@googlemail.com 2008-05-23 06:56:44 --- I rebuild wine 0.9.45 it worked just fine? Did you make wineprefixcreate before you ran wine? This is required and I am not sure if you would not need to remove completly your .wine folder, because the diffs between today and pre 2 year old wine versions are quite big
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #22 from Tony Wasserka tony.wasserka@freenet.de 2008-05-23 07:09:58 --- This shouldn't be needed as there are only configuration files and the virtual C: partition in .wine, whereas this is a problem with the wine libs which are stored in e.g. /usr/local/libs/wine. Moreover, I don't really want to spend so much time on always reinstalling warcraft into a new wineprefix, especially because I'm quite short of time this week. Also, I once fixed this bug by reverting one special patch by Roderick Colenbrander (something about aux buffers, don't know exactly anymore). However, reverting that one doesn't seem to work anymore (and he also said that the patch was okay), so this isn't an option anymore.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #23 from MGSX2 mgsx2@hotmail.com 2008-05-23 07:36:20 --- soxs: Can you tell us your system specifications, distribution, and driver version?
I somehow doubt that it's a wine-only problem and on the other hand it doesn't seem to be a ATI-only problem, so it has to be a special constellation that makes WC3 run or not.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #24 from soxs schuster.bernhard@googlemail.com 2008-05-23 14:28:19 --- Phenom 9500 X4 3870 RadeonHD 512 MB factory OC 4 GB of RAM @ 800Mhz
I've got 2 of them, and when I created a package, it was like playing roulette if both show the error, only one shows the error or no error at all. that's really strange
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #25 from MGSX2 mgsx2@hotmail.com 2008-05-23 14:50:30 --- Which distribution?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #26 from soxs schuster.bernhard@googlemail.com 2008-05-23 17:56:10 --- Ubuntu 8.04 Hardy heron x86_64 tested wine versions: 0.9.58 (works most of times) 0.9.45 always worked untill now 0.9.59 - 0.9.61 never worked 1.0rc1 wacky like hell
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #27 from Tony Wasserka tony.wasserka@freenet.de 2008-05-24 02:58:08 --- I can confirm that things are a bit strange... Tried out 0.9.30 and sometimes it worked, sometimes it spitted out the error message and sometimes it spitted it out twice or even three times.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #28 from Tony Wasserka tony.wasserka@freenet.de 2008-05-24 04:09:09 --- Okay, using Wine 0.9.58 and an own wineprefix, I ran Warcraft several times, and it always gave me that error. So, at least for me, this bug also affect 0.9.58. Using Fedora 8.
http://bugs.winehq.org/show_bug.cgi?id=13335
QuoosX quoosx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |quoosx@gmail.com
--- Comment #29 from QuoosX quoosx@gmail.com 2008-05-25 04:06:57 --- I really have no clue if I hit the same error or not, since I use the free radeon driver for a Radeon RV250 [Mobility FireGL 9000] on FreeBSD 7.0.
0.9.56 works fine for me.
Starting with 0.9.57, performance has dropped down to an unbearable level. I assumed it was opengl related, since some of the intro screen was missing in the same way I had seen much earlier when dri was disabled.
Some time later (I guess 0.9.59 or 0.9.60), the artifacts on the intro screen were gone, but it was still slow and unplayable.
With 1.0.r2, on the first run I got an error message: X Error of failed request: GLXBadDrawable Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 581 Current serial number in output stream: 581
On the second run, the game does start with the same slow performance as before. (Removing ~/.wine and reinstalling did not help either.)
Needless to say, if I go back to 0.9.56 without changing anything else, the game runs fine.
These additional error messages show up in 1.0.r2 comparing to 0.9.56: err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 err:iphlpapi:getRouteTable Unexpected address type 0x10 err:iphlpapi:getRouteTable Unexpected address type 0x20
BTW: I do use the wine-kthread patch that is required for Warcraft III on FreeBSD. Additionally, I use the CompletionPort patch, but I did the same testing without it, too, getting the same results.
Versions that I did test without success: 0.9.57, 0.9.58, 0.9.59, 0.9.60, 0.9.61, and 1.0.r2. (Most of 0.9.44 to 0.9.56 patched as above do work.)
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #30 from Rich Rincebrain@gmail.com 2008-05-25 04:13:51 --- I'd have to recommend doing git bisect to find out where, exactly, this goes terribly wrong.
There's a howto on the wiki (http://wiki.winehq.org/RegressionTesting), but the important parts are to start a bisect (git bisect start), tag 0.9.56 as good (git reset --hard wine-0.9.56;git bisect good), then tag 0.9.57 as bad (git reset --hard wine-0.9.57;git bisect bad), and then repeat. You'll only have to do log(N) (rounded up) compiles, where N is the number of commits it tells you are left. Conveniently, since it's just between one revision of wine, it's only about 2 weeks of commits, and ccache will probably be very helpful to you. :)
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #31 from QuoosX quoosx@gmail.com 2008-05-25 18:12:07 --- Created an attachment (id=13340) --> (http://bugs.winehq.org/attachment.cgi?id=13340) reintroduce X11DRV_setup_opengl_visual
220163ee9d698543fe34257969a88e5976d378de broke it for me. This patch undoes it in 1.0.r2.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #32 from QuoosX quoosx@gmail.com 2008-05-25 18:20:23 --- Today, I learned more about git, ccache, and some FreeBSD specifics than I wished. (I never tried a bisect because of the 45 minutes each compile takes on my machine.)
I found that this commit broke it for me:
commit 220163ee9d698543fe34257969a88e5976d378de Author: Roderick Colenbrander < thunderbird2k * gmx * net > Date: Fri Feb 22 20:55:02 2008 +0000 wgl: Remove unneeded opengl initialisation code at wine startup.
Undoing it, makes the game run properly on 1.0.r2.
I guess the next step is contacting the author of the commit...
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #33 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-26 03:43:42 --- There are two different issues here a bug which causes FGLRX to fall back to software rendering. This is a driver issue and I'm not sure why it happens (in some cases the ATI driver option UseFastTLS can do miracles).
The other issue is the GLXBadDrawable which happens at least on the open source radeon driver. The code which got removed really isn't needed. I have no idea why you would need the init code. Before we only had a single opengl pixel format and for that reason we had to choose a special format at Wine startup (that's what that code did). That limitation was lifted and that's why the code wasn't needed anymore. The OpenGL code now chooses the format it wants. When we select a different pixel format we need to create an opengl window (when we had a single format we didn't do this as we had to share the window with the main window of the program). Likely this code is failing for you OR you are suffering from a driver bug as it works for most other users.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #34 from QuoosX quoosx@gmail.com 2008-05-26 06:43:43 --- Ok, I guess I have hijacked this bug for a different one. (Both with ATI, slow rendering, and introduced about at the same version.)
Shall I open a new bug report to discuss my problem further? Overall, it is a regression that needs to be fixed, even if the code removal that triggered the bug was correct.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #35 from MGSX2 mgsx2@hotmail.com 2008-05-26 06:47:00 ---
(in some cases the ATI driver option UseFastTLS can do miracles).
I should have mentioned that. UseFastTLS was disabled at my computer ("2") and I didn't work too.
http://bugs.winehq.org/show_bug.cgi?id=13335
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dankeris@gmail.com
--- Comment #36 from Austin English austinenglish@gmail.com 2008-05-26 10:39:20 --- *** Bug 13414 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #37 from Tony Wasserka tony.wasserka@freenet.de 2008-05-26 11:03:00 --- Reverting 220163ee9d698543fe34257969a88e5976d378de also fixed the problem for me. The errors still occur but it doesn't seem to affect the performance, thank you so much :D However, perhaps someone could try the minimize the code in the now re-added function in order to find the problematic code.
Ok, I guess I have hijacked this bug for a different one. (Both with ATI, slow rendering, and introduced about at the same version.)
Shall I open a new bug report to discuss my problem further? Overall, it is a regression that needs to be fixed, even if the code removal that triggered the bug was correct.
No, that isn't valid. You can't call a bug "reproducable" if it needs a patch to occur. Better wait for anyone to fix this one issue and try it again. Probably just some code that was re-added now conflicts with the newer code.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #38 from Tony Wasserka tony.wasserka@freenet.de 2008-05-26 11:06:26 --- hm... tried it a second time and it doesn't work anymore. Really strange... Guess something is REALLY screwed up hard here...
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #39 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-26 12:51:22 --- To be honest I think that the ATI drivers contain some Wine specific hack. The code in question only preselecting a pixel format. In general apps request a totally different format than the default. The code also won't be re-added as preselecting an OpenGL capable pixel format was done for ALL programs even for apps that didn't need OpenGL/Direct3D and this caused issues apart from that it is unneeded.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #40 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-31 03:42:18 --- As mentioned before both fglrx and the open source radeon driver are suffering from a different bug. I think I know what is the problem. Could users of both drivers (please mention driver + card) attach the output of both glxinfo and xdpyinfo to here?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #41 from Tony Wasserka tony.wasserka@freenet.de 2008-05-31 04:00:41 --- Using Catalyst 8.5/fglrx 8.493 on a Sapphire ATI X1600 Pro (512 MB) AGP.
glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: Radeon X1600 Series OpenGL version string: 2.1.7415 Release OpenGL extensions: GL_AMD_performance_monitor, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil, GL_ATI_texture_compression_3dc, GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texgen_reflection, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_WIN_swap_hint, WGL_EXT_swap_control
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x2f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x32 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x33 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x34 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x35 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x36 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x37 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x38 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x39 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x3a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x3b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x3c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x3d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x3e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x3f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x40 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x41 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x42 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x43 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x44 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x45 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x46 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x47 24 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x48 24 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x49 24 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x4a 24 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x4b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x4c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x4d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x4e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x4f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x50 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x51 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x52 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x53 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x54 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x55 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x56 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x57 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x58 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x59 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x5c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x5d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x5e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x5f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x60 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x61 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x62 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x63 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x64 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x65 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x66 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x67 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x68 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x69 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x6a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x6b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x6c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x6d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x6e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x6f 24 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x70 24 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x71 24 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x72 24 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x89 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon
xdpyinfo: name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 10300000 X.Org version: 1.3.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0xa00001, revert to PointerRoot number of extensions: 37 ATIFGLEXTENSION ATIFGLRXDRI ATITVOUT BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo glesx default screen number: 0 number of screens: 1
screen #0: dimensions: 1280x1024 pixels (342x271 millimeters) resolution: 95x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x8b depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0xfac031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 81 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x27 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x28 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x29 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2a class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2b class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2c class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2d class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2e class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2f class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x30 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x31 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x32 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x33 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x34 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x35 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x36 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x37 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x38 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x39 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3a class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3b class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3c class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3d class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3e class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x3f class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x40 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x41 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x42 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x43 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x44 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x45 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x46 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x47 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x48 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x49 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4a class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4b class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4c class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4d class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4e class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x4f class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x50 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x51 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x52 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x53 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x54 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x55 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x56 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x57 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x58 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x59 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5a class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5b class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5c class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5d class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5e class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5f class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x60 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x61 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x62 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x63 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x64 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x65 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x66 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x67 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x68 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x69 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6a class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6b class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6c class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6d class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6e class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6f class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x70 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x71 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x72 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x89 class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #42 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-31 05:03:28 --- Next time please use an attachment.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #43 from soxs schuster.bernhard@googlemail.com 2008-05-31 05:11:41 --- Created an attachment (id=13523) --> (http://bugs.winehq.org/attachment.cgi?id=13523) RadeonHD 3870, fglrx 8.5, glxinfo output
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #44 from soxs schuster.bernhard@googlemail.com 2008-05-31 05:12:08 --- Created an attachment (id=13525) --> (http://bugs.winehq.org/attachment.cgi?id=13525) RadeonHD 3870, fglrx 8.5, xdpyinfo output
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #45 from soxs schuster.bernhard@googlemail.com 2008-05-31 05:12:55 --- Attached both log outputs, using fglrx 8.5 and and an RadeonHD 3870
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #46 from QuoosX quoosx@gmail.com 2008-06-02 10:30:55 --- Created an attachment (id=13571) --> (http://bugs.winehq.org/attachment.cgi?id=13571) glxinfo ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #47 from QuoosX quoosx@gmail.com 2008-06-02 10:31:58 --- Created an attachment (id=13572) --> (http://bugs.winehq.org/attachment.cgi?id=13572) xdpyinfo ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #48 from QuoosX quoosx@gmail.com 2008-06-02 11:13:04 --- With wine-1.0.r3, the behavior is the same, but I have never seen GLXBadDrawable again -- even after cleaning ~/.wine.
The "slow" version without and the "good" version with X11DRV_setup_opengl_visual both produce the same error messages:
err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 err:iphlpapi:getRouteTable Unexpected address type 0x10 err:iphlpapi:getRouteTable Unexpected address type 0x20 err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 err:iphlpapi:getRouteTable Unexpected address type 0x10 err:iphlpapi:getRouteTable Unexpected address type 0x20 err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x33f400,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f6ac,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f6dc,0x00000000), stub! fixme:imm:ImmAssociateContextEx (0x30024, 0x0, 16): stub
Besides the getRouteTable errors, AFAIR, they have all been there for every wine version that could run Warcraft III on FreeBSD. (This is still all for the free radeon driver.)
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmx.net
--- Comment #49 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-08 02:07:52 --- Somewhere around line 300 in dlls/winex11.drv/opengl.c you'll see (inside InitOpenGLInfo): visual = DefaultVisual(gdi_display, screen); template.visualid = XVisualIDFromVisual(visual); vis = XGetVisualInfo(gdi_display, VisualIDMask, &template, &num);
Behind 'vis = ...' add: ERR("visualid: %x\n", vis->visualid);
Then post the log +wgl output in the slow and fast case. I'll try to match it to the glxinfo / xdpyinfo logs you provided.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #50 from QuoosX quoosx@gmail.com 2008-06-08 05:46:57 --- I have marked the lines that only appear in the fast [PATCHED] version, that only appear in the slow [UNPATCHED] version, and that only appear on the initial [1st] run after reinstall. (The address in the last line differs, too, but I guess that is irrelevant.)
err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 err:iphlpapi:getRouteTable Unexpected address type 0x10 err:iphlpapi:getRouteTable Unexpected address type 0x20 err:winedevice:ServiceMain driver L"DgiVecp" failed to load [PATCHED]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 [PATCHED]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 err:iphlpapi:getRouteTable Unexpected address type 0x10 err:iphlpapi:getRouteTable Unexpected address type 0x20 [PATCHED][1st]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 [1st]Could not load Mozilla. HTML rendering will be disabled. [1st]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 [1st]wine: configuration in '/home/jan/.wine' has been updated. [PATCHED][1st]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 err:ole:CoCreateInstance apartment not initialised [UNPATCHED]err:wgl:X11DRV_WineGL_InitOpenglInfo visualid: 23 fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x33f400,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f6ac,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f6dc,0x00000000), stub! fixme:imm:ImmAssociateContextEx (0xf0024, 0x0, 16): stub
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #51 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-08 07:54:09 --- On what card it was? I don't see anything special.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #52 from QuoosX quoosx@gmail.com 2008-06-08 09:05:05 --- Since you did not tell me to do so, I did not open a new bug report for the second issue... maybe I should?
ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI
It is the one with the free radeon driver (R200) that broke after X11DRV_setup_opengl_visual was removed.
Or is there anything else you want to know about my card?
http://bugs.winehq.org/show_bug.cgi?id=13335
Dmitry bloodhound@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bloodhound@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=13335
Forrest Loomis cybercyst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybercyst@gmail.com
--- Comment #53 from Forrest Loomis cybercyst@gmail.com 2008-06-25 13:54:10 --- (In reply to comment #0)
In the near past, whenever trying to run warcraft via wine, I get two libGL errors. Afterwards, I get told, that mesa will get used instead. So performence goes really bad. I get about 10-20fps instead of 120-160fps, though I have an insane gaming rig. The only way to fix it, is removing the ~/.wine directory completly. But that's not an real option...
OK, I've been having the libGL drmMap errors with wine and fglrx too. Card specs: ATI Radeon HD2600
I started doing the Regression testing, I noticed that 3d still works with wine-0.9.58! So I can play WoW at least. :)
wine-0.9.59 exhibits strange behavior, no libGL drmMap error, but the screen goes black, (sound is still going, so it just seems that gl started to be broken here)
wine-0.9.60 and up till the latest have the libGL drmMap error.
So, my regression testing shows that the last state that 3d was working (before the screen would just be all black) with fglrx cards was with commit: # bad: [9b79bc5e31cb40f7f700a1678a08b0985e6bc951] wined3d: Implement env bump mapping in the atifs ffp replacement. git-bisect bad 9b79bc5e31cb40f7f700a1678a08b0985e6bc951
I hope this can help... I am now doing regression testing to see when the libGL drmMap error first shows up.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #54 from soxs schuster.bernhard@googlemail.com 2008-06-26 03:52:13 --- I upgraded my driver from 8.4 to 8.6 and since then, I get the libGL even with 0.9.45 ! I recompiled it, but it did not do make any difference. (Ati RadeonHD 3870)
http://bugs.winehq.org/show_bug.cgi?id=13335
Forrest Loomis cybercyst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #55 from Forrest Loomis cybercyst@gmail.com 2008-06-26 14:01:31 --- Created an attachment (id=14372) --> (http://bugs.winehq.org/attachment.cgi?id=14372) makes 3d work with the fglrx driver
I finally bisected the libGL drmMap error to this commit: 195ca1e85f01ac40695fbb6fcf9e9e130265f091
So you can run git revert 195ca1e85f01ac40695fbb6fcf9e9e130265f091 and recompile wine to get 3d going, or you can use this patch to revert those changes.
As far as I can tell, everything else is still working under wine (all the programs I use) and 3d is working again!
I have a M76 - Radeon Mobility HD2600 with the Catalyst 8.6 (fglrx 8.50.3) driver installed. World of Warcraft now runs very very well, as does various 3d demos I've grabbed off the net.
So apply the patch (or revert that commit) and say if it fixes it for you!
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #56 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-26 15:08:25 --- Wine is doing some evil memory stuff. In short at wine startup we reserve all virtual memory. Dlls and apps need to be loaded in specific parts. Likely there isn't enough virtual memory left for ATI's driver. Alexandre suggested that we might need to do very evil stuff (e.g. override mmap calls made by the driver) in order to fix it. I think a fix is a long time away, so for now revert that patch as I don't think it will be reverted. Note that it might not work for others at all.
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE
--- Comment #57 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-27 06:59:29 --- This is the same as 12929.
*** This bug has been marked as a duplicate of bug 12929 ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |
--- Comment #58 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-27 07:14:00 --- I didn't read it properly, it isn't a duplicate ..
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #59 from Forrest Loomis cybercyst@gmail.com 2008-06-27 09:51:31 --- OK, well it seems the above regression only gives limited success. Warcraft III still throws a libGL error.
At least World of Warcraft works with this regression, as well as some other programs now...
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #60 from Forrest Loomis cybercyst@gmail.com 2008-06-27 10:56:16 --- Created an attachment (id=14394) --> (http://bugs.winehq.org/attachment.cgi?id=14394) update to the above X11 patch for 1.0
The above X11 patch didn't apply cleanly on the 1.0 tree for me. Here is an updated version.
With that patch, and the preloader patch I can play Warcraft III without the libGL error!
30 fps with the patches, only 11 without -- seems capped around 30fps then, but it is smooth.
http://bugs.winehq.org/show_bug.cgi?id=13335
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #61 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-27 11:52:02 --- Are you sure that the GL patch is also needed? It doesn't do anything special. If it does anything either the fbconfig is different but likely it triggers some wine workaround in the ati drivers.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #62 from Forrest Loomis cybercyst@gmail.com 2008-06-27 12:30:26 --- Yeah, at least on my system I tried compiling wine reverting the preloader patch only. This makes World of Warcraft and fr08v101.exe (a free opengl demo at 96k that you can download online) work, as in no libGL error.
However, with Warcraft III I still get the libGL error.
Applying only the above patch (reintroduce X11DRV setup opengl visual) I always get the libGL error.
Applying both of them, and Warcraft III works.
http://bugs.winehq.org/show_bug.cgi?id=13335
Michael schnitzelkuchen@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schnitzelkuchen@googlemail.c | |om
--- Comment #63 from Michael schnitzelkuchen@googlemail.com 2008-07-07 05:25:36 --- I can confirm the problem here.
The new wine releases seem to be very good, its a pity that i cant use them without having to patch them before. Someone knows if one of those patches will get back into the main tree of wine ?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #64 from Roderick Colenbrander thunderbird2k@gmx.net 2008-07-07 05:57:33 --- These patches are hacks. In short wine emulates the windows memory layout and reserves a lot of virtual memory for this. Only a few hundred MB is left for system libraies like libGL.so. The ati driver doesn't like this layout (perhaps it wants large ranges and we are offering small chunks). What we need to do is to wrap all memory allocation calls (malloc, mmap ..), so that native libGL.so uses 'win32 memory' but this is quite tricky. It is the only solution.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #65 from Bellegueulle Damien bellegueulle.damien@neuf.fr 2008-07-17 13:59:13 --- Created an attachment (id=14875) --> (http://bugs.winehq.org/attachment.cgi?id=14875) Log with all patch in the page ...
ATI 4850HG Fglrx 8.6 Kernel 2.6.25 Wine 1.1.1 Git ( 17/07/08 )
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1: "Fragment shader was successfully compiled to run on hardware.\nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported" fixme:d3d9:Direct3DShaderValidatorCreate9 stub
= CRASH
http://bugs.winehq.org/show_bug.cgi?id=13335
Tesseract tesseract.pl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tesseract.pl@gmail.com
--- Comment #66 from Tesseract tesseract.pl@gmail.com 2008-07-23 12:08:57 --- The bug seems to be fixed for me when I use "ulimit -s unlimited" before launching OpenGL games in wine. I tried various workarounds provided here and on the other bug pages, but they didn't help at all. The preloader patch even made running WoW impossible. Now everything works just fine, with no flaws on highest detail level.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #67 from Tony Wasserka tony.wasserka@freenet.de 2008-07-23 12:34:29 ---
The bug seems to be fixed for me when I use "ulimit -s unlimited" before launching OpenGL games in wine. I tried various workarounds provided here and on the other bug pages, but they didn't help at all. The preloader patch even made running WoW impossible. Now everything works just fine, with no flaws on highest detail level.
Works for me too, thank you very much! Now I can finally play my windows games under wine again :D
...well apart from that windowed mode and some 3d games do not work due to graphics corruption, but at least it's a step.
Hope this fixes the bug for others, too!
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #68 from soxs schuster.bernhard@googlemail.com 2008-07-23 14:23:43 --- The bug seems to be fixed for me when I use "ulimit -s unlimited" before launching OpenGL games in wine. I tried various workarounds provided here and on the other bug pages, but they didn't help at all. The preloader patch even made running WoW impossible. Now everything works just fine, with no flaws on highest detail level.
Where do I have to write/post "ulimit -s unlimited"?? in terminal just before i run? Any prefixes required. Plx help....
http://bugs.winehq.org/show_bug.cgi?id=13335
BlackStar BurnSpamAddress@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |BurnSpamAddress@gmail.com
--- Comment #69 from BlackStar BurnSpamAddress@gmail.com 2008-07-23 14:36:16 --- I've encountered the exact same libGL error with OpenGL programs outside Wine:
libGL error: drmGetMagic failed libGL error: reverting to (slow) indirect rendering
This is definitely an fglrx bug, and seems linked to opening more than one display connection. I can easily reproduce the bug with code like this:
dpy = XOpenDisplay(); visual = glXChooseVisual(dpy); XCloseDisplay(dpy); ... dpy2 = XOpenDisplay(); ctx = glXCreateContext(dpy2, visual); /* fglrx reverts to indirect rendering */
I've tested the above code with fglrx versions up to 8.5, and it reproduces the bug 100% of the times. If you do not close the first display connection the bug still occurs, albeit not always.
Several applications seem affected by this, including VLC Media Player. It might be worth it to check whether Wine uses multiple display connections.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #70 from BlackStar BurnSpamAddress@gmail.com 2008-07-23 14:39:02 --- Possibly related bug reports:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462715
http://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge...
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #71 from Tesseract tesseract.pl@gmail.com 2008-07-23 14:51:20 --- (In reply to comment #68)
Where do I have to write/post "ulimit -s unlimited"?? in terminal just before i run? Any prefixes required. Plx help....
Yeah, in the same terminal window. So, basically, you have to first type "ulimit -s unlimited" (there will be no output in terminal) and then run wine WoW.exe for example. If you will close terminal window, you will have to run ulimit again (changing stack size works only for one session).
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #72 from Alexandre Julliard julliard@winehq.org 2008-07-23 16:48:32 --- (In reply to comment #69)
Several applications seem affected by this, including VLC Media Player. It might be worth it to check whether Wine uses multiple display connections.
It definitely does.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #73 from Vitaliy Margolen vitaliy@kievinfo.com 2008-07-24 18:42:02 --- So back to closed invalid then since none of the things listed are Wine bugs?
http://bugs.winehq.org/show_bug.cgi?id=13335
chris ahrendt celticht32@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |celticht32@aol.com
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #74 from chris ahrendt celticht32@aol.com 2008-07-26 21:35:45 --- *** Bug 14072 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #75 from chris ahrendt celticht32@aol.com 2008-07-30 23:02:55 --- Try this simple fix... I think I found it tonight....
x11drv_main.c
/*********************************************************************** * X11DRV process initialisation routine */ static BOOL process_attach(void)
then about 2 lines down change to this :
if (!(gdi_display = XOpenDisplay( NULL ))) return FALSE; display = gdi_display;
This seems to fix it without the ulimit -s fix.. Please let me know if others have the same success...
chris
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #76 from Tony Wasserka tony.wasserka@freenet.de 2008-07-31 10:48:22 ---
Try this simple fix...
Sorry, doesn't work for me here :-/
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #77 from chris ahrendt celticht32@aol.com 2008-07-31 11:44:01 --- Maybe Its my configuration
I am running RHEL 5 with the latest ATI drivers and the latest GIT tree.
Chris
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #78 from Tesseract tesseract.pl@gmail.com 2008-07-31 15:26:22 --- (In reply to comment #75)
Try this simple fix...
This doesn't work for me either. Maybe you compiled wine with ulimit and then run game in the same session, so unlimited stack size was still active? Anyway, I still don't have libGL errors with unlimited stack size, but WoW started to lock up very often, like every two minutes. The only thing I can do is to kill it with ctrl+c. There aren't any signs of error in console output, maybe I'll try to use debugger later. I have a suspicion it is somehow connected with cursor, because it locks up when moving mouse. Those lock ups don't occur without ulimit, but there are so many glitches that game is unplayable.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #79 from chris ahrendt celticht32@aol.com 2008-08-02 13:31:21 --- no I dont think its that as I removed it also did a ulimit -l and made sure it was not unlimited. But one thing that is different.. I was running a later kernal than I am now.. and now that I downgraded to a earlier one it is back
chris
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #80 from chris ahrendt celticht32@aol.com 2008-08-05 11:12:48 --- One further bit of weirdness...
when I run the ulimit -s unlimited
I start EverQuest2.exe up... the whole screen goes black (even when running in virtual desktop mode) and the virtual desktop section begins to update.. I see that.. the window that I run EQ2 from updates and I see the trace logs, but the remainder of the screen is blank until I get a font load error and the app shuts down. Then I can move windows around and the background updates but areas still have black sections on them. These remain until I restart X.
Chris
http://bugs.winehq.org/show_bug.cgi?id=13335
Henning Fleddermann SickThought@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |SickThought@gmx.net
--- Comment #81 from Henning Fleddermann SickThought@gmx.net 2008-08-16 07:31:52 --- After reading through this bug I'm fairly sure it's got something to do with the x86_64 architecture. As far as I can tell everyone who reported the bug is using x86_64. I'm also getting this bug on x86_64 with both the fglrx- and the radeon-driver. Weird: I get the libGL-error-messages, and the menu screen has corruption, but performance seems to be good (can play fluently) and in-game there seems to be no corruption. Wine-version is 1.1.0 (no patch was applied).
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #82 from Tony Wasserka tony.wasserka@freenet.de 2008-08-16 07:43:23 ---
After reading through this bug I'm fairly sure it's got something to do with the x86_64 architecture. As far as I can tell everyone who reported the bug is using x86_64. I'm also getting this bug on x86_64 with both the fglrx- and the radeon-driver. Weird: I get the libGL-error-messages, and the menu screen has corruption, but performance seems to be good (can play fluently) and in-game there seems to be no corruption. Wine-version is 1.1.0 (no patch was applied).
Sorry, but I'm on x86 and get the error, too. The menu and also the ingame are corrupted and run at no usuable speed, so your experience is quite different from mine ;-)
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.keusch@gmx.at
--- Comment #83 from Roderick Colenbrander thunderbird2k@gmx.net 2008-08-16 10:50:23 --- *** Bug 14689 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #84 from Tesseract tesseract.pl@gmail.com 2008-08-18 11:22:17 --- (In reply to comment #81)
After reading through this bug I'm fairly sure it's got something to do with the x86_64 architecture. As far as I can tell everyone who reported the bug is using x86_64. I'm also getting this bug on x86_64 with both the fglrx- and the radeon-driver. Weird: I get the libGL-error-messages, and the menu screen has corruption, but performance seems to be good (can play fluently) and in-game there seems to be no corruption. Wine-version is 1.1.0 (no patch was applied).
Well, I'm running 32-bit version of Fedora, so it's probably not connected with it. The only way to get rid of it for me is to use unlimited stack size, but this causes random lock-ups for me without any wine or fglrx errors in console. The game just freezes and I have absolutely no idea where do they come from. The only sure thing is that lock-ups happen only when using ulimit. Anyway, the 8.8 fglrx drivers are coming soon and I hope AMD developers will manage to fix it.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #85 from Henning Fleddermann SickThought@gmx.net 2008-08-23 05:53:39 --- I tried fglrx 8.8 yesterday and the bug is not fixed.
Also I've got some additions/corrections to my previous comments: I was wrong about the performance being ok. It looked like that because my cpu seems to be beefy enough to render WC3 in software mode. But more demanding games (WoW eg.) are very slow or crash (Max Payne 2). Also ulimit -s unlimited does not fix the bug for me, not with fglrx and neither with radeon.
What puzzles me is that this bug happens with fglrx _and_ radeon (with Mesa from git). It really seems to be more of a wine bug that a driver bug. Comment #64 seems to make sense.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #86 from Tony Wasserka tony.wasserka@freenet.de 2008-08-23 09:39:07 ---
I tried fglrx 8.8 yesterday and the bug is not fixed.
Try to apply the "reintroduce X11DRV_setup_opengl_visual" patch from the attachements (which will need "some" modifications to cleanly apply though), recompile Wine, call ulimit -s unlimited and then run a 3D app under Wine. This way it works on my computer.
http://bugs.winehq.org/show_bug.cgi?id=13335
Josh Jones joshorjeff@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joshorjeff@gmail.com
--- Comment #87 from Josh Jones joshorjeff@gmail.com 2008-09-13 18:16:58 --- I realise someone else has said that disabling/enabling AIGLX doesn't affect this issue, however I've just found that under 1.1.4, if I have AIGLX disabled in xorg.conf, the game gives the GL error and runs using mesa (ie. slow). If I turn on AIGLX in xorg.conf and restart X, the game then runs. This doesnt seem to depend on the composite extension because it has worked both with it enabled and with it disabled.
I am using version 8.47.3 of the fglrx driver as provided by Ubuntu.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #88 from Stev47 stephan@ehilb.de 2008-10-08 13:07:59 --- setting chmod 666 on /dev/dri/card0 solved for me the problem
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #89 from chris ahrendt celticht32@aol.com 2008-10-14 18:48:08 --- did not fix the issue for me...
chris
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #90 from soxs schuster.bernhard@googlemail.com 2008-10-15 09:46:34 --- I got something: Whenever I only install 0.9.45 everything runs fine. So far so good, no libGL errors at all. As soon as I install 1.x I get libGL errors when runnin warcraft with 0.9.45!!! aswell as with 1.x...
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #91 from Tony Wasserka tony.wasserka@freenet.de 2008-10-15 11:14:18 --- Okay, one last time: 1. Apply this (http://bugs.winehq.org/attachment.cgi?id=13340) patch to your local wine tree (you'll need to modify it a bit). 2. Compile Wine and install it. 3. call ulimit -s unlimited before you start wine 4. call wine <application-name> and it should work alright (and it actually did so on my two (fundamental different) computers)
Somebody PLEASE close this bug, this workaround is the only one which seems to work everywhere.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #92 from chris ahrendt celticht32@aol.com 2008-10-15 11:22:23 --- has the patch gotten into the main git tree yet?
chris
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #93 from Tony Wasserka tony.wasserka@freenet.de 2008-10-15 12:25:09 --- No, it hasn't and there is no need to as is explained at http://bugs.winehq.org/show_bug.cgi?id=13335#c56 and http://bugs.winehq.org/show_bug.cgi?id=13335#c64. Before anyone else asks, READ COMMENT #91.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #94 from Rich Rincebrain@gmail.com 2008-10-15 16:14:23 --- Please do not demand that the bug be closed because there is a hackish workaround.
The bug should be closed when either the problem is actually fixed or it is decided that it won't be fixed - in either case, having a terrible workaround is not a Fix.
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paulc@voip.null.ro
--- Comment #95 from Roderick Colenbrander thunderbird2k@gmx.net 2008-10-18 16:11:22 --- *** Bug 15665 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Component|-unknown |opengl Target Milestone|--- |1.2.0
--- Comment #96 from Roderick Colenbrander thunderbird2k@gmx.net 2008-10-18 16:16:21 --- Marking this bug as a major one for Wine 1.2. As mentioned the main bug is that we run out of virtual memory for native linux/freebsd/mac libraries. This is caused by Wine's virtual memory reservation behavior. This issue should be fixed by mapping native memory functions (malloc and friends) to win32 heapalloc.
At this point the bug manifests itselfs in two ways. First of all ATI's fglrx can run out of virtual memory at Wine startup and falls back to indirect rendering. A sign of this in general is some drmMap message and 'indirect rendering' showing up using WINEDEBUG=+wgl. For a part this could be a driver bug as reusing the same display connection seeems to avoid it (likely that saves memory and that prevents the issue from happening). The second way in which this manifests itself is OpenGL running out of memory with GL_OUT_OF_MEMORY. Note that not all cases of GL_OUT_OF_MEMORY are this issue.
http://bugs.winehq.org/show_bug.cgi?id=13335
andy-wine@splashground.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andy-wine@splashground.de
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #97 from Alexandre Julliard julliard@winehq.org 2008-11-10 07:59:59 --- Created an attachment (id=17197) --> (http://bugs.winehq.org/attachment.cgi?id=17197) mmap wrappers
Give this a try.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #98 from Tony Wasserka tony.wasserka@freenet.de 2008-11-10 08:45:08 ---
Created an attachment (id=17197)
--> (http://bugs.winehq.org/attachment.cgi?id=17197) [details]
mmap wrappers
Give this a try.
Works fine for me on a 64 bit system using Catalyst 8.10 on a 3850, thanks.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #99 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-10 08:55:29 --- Did you have issues like drmMap or fallbacks to software rendering before? If so did it fix those too?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #100 from Forrest Loomis cybercyst@gmail.com 2008-11-10 09:01:48 --- (In reply to comment #97)
Created an attachment (id=17197)
--> (http://bugs.winehq.org/attachment.cgi?id=17197) [details]
mmap wrappers
Give this a try.
This also fixes it for me. I am running an amd64 system with the Catalyst 8.10 drivers. I had the drmMap errors with all 3d games and they all work now.
Thank you so much for the awesome patch!
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #101 from Tony Wasserka tony.wasserka@freenet.de 2008-11-10 10:08:22 ---
Did you have issues like drmMap or fallbacks to software rendering before? If so did it fix those too?
Yeah, I always got the libGL error: drmMap of framebuffer failed (Not enough memory) libGL error: reverting to (slow) indirect rendering when launching 3D apps in Wine (sometimes even by just launching wine at all).
I workarounded this by applying the "reintroduce X11DRV_setup_opengl_visual" patch and calling ulimit -s unlimited before running Wine, but with the mmap patch it works fine without changing the stack limit.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #102 from Henning Fleddermann SickThought@gmx.net 2008-11-10 15:42:43 --- (In reply to comment #97)
Created an attachment (id=17197)
--> (http://bugs.winehq.org/attachment.cgi?id=17197) [details]
mmap wrappers
Give this a try.
Fixed the bug for me, thanks alot. Gentoo, amd64, X Server 1.5.2 and catalyst 8.543.
http://bugs.winehq.org/show_bug.cgi?id=13335
Seppo Yli-Olli seppo.yli-olli@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |seppo.yli-olli@iki.fi
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #103 from Seppo Yli-Olli seppo.yli-olli@iki.fi 2008-11-14 10:05:07 --- *** Bug 16040 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Rainer Wittmaack ningo@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ningo@gmx.net
--- Comment #104 from Rainer Wittmaack ningo@gmx.net 2008-11-16 21:18:50 --- I have no problems starting Warcraft III after applying this patch. But when I start WC3 without -window and switch virtual desktops or do any other action that puts wc3 into the background the screen becomes garbled.
See http://h-quer.org/tmp/wc3_corruption.jpg as an example.
It's irrelevant wether WC3 is really fullscreen or not, as long as the "-window" flag is not passed, WC3 WILL corrupt.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #105 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-17 02:37:25 --- I believe there is another bug for the garbling in warcraft 3. For a part it might be related to the fact that Windows doesn't know virtual desktops and has the ability (if the game asks for it) to lock to the game. So the game might be entering an unknown situation but I'm not sure.
http://bugs.winehq.org/show_bug.cgi?id=13335
Carth Carth_Onasi@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Carth_Onasi@centrum.cz
--- Comment #106 from Carth Carth_Onasi@centrum.cz 2008-11-20 00:22:33 --- I downloaded new driver 8.11 and it seems, then there is no message like:
libGL error: drmMap of framebuffer failed (Not enough memory) libGL error: reverting to (slow) indirect rendering
Before I always have this, when I try to run any DirectX game. And it is working without patch.
My confiruration: Mandriva 2008.1 64-bit + Wine 1.1.8(NOT patched) + Catalyst 8.11 on laptop ASUS F3Ka (AMD Turion X2 + ATI Radeon HD2600 + AMD 690G)
http://bugs.winehq.org/show_bug.cgi?id=13335
JH jorgen.hedlund@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jorgen.hedlund@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13335
Adys adys.wh+winehqdotorg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh+winehqdotorg@gmail.c | |om
--- Comment #107 from Adys adys.wh+winehqdotorg@gmail.com 2008-11-28 13:36:05 --- mmap patch does not apply to current git anymore.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #108 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-29 10:17:04 --- Created an attachment (id=17538) --> (http://bugs.winehq.org/attachment.cgi?id=17538) Updated version of mmap patch against git from 28/11/2008
The original mmap patch was made before some restructuring in ntdll. During the restructuring some code was removed causing this patch not to apply anymore. This patch was made against git from 28/11/2008 but it should also work fine against 1.1.9.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #109 from Xzarr xzarr@lavabit.com 2008-11-29 15:13:46 --- Created an attachment (id=17540) --> (http://bugs.winehq.org/attachment.cgi?id=17540) log of using wine 1.1.9 with mmap patch against git from 28/11/2008
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17540|0 |1 is obsolete| |
--- Comment #110 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-29 17:08:08 --- (From update of attachment 17540) This patch contains some misstakes.
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17540|1 |0 is obsolete| |
--- Comment #111 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-29 17:08:20 --- (From update of attachment 17540) Oops.
http://bugs.winehq.org/show_bug.cgi?id=13335
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17538|0 |1 is obsolete| |
--- Comment #112 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-29 17:08:34 --- (From update of attachment 17538) This patch is wrong.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #113 from Roderick Colenbrander thunderbird2k@gmx.net 2008-11-29 17:09:43 --- Created an attachment (id=17547) --> (http://bugs.winehq.org/attachment.cgi?id=17547) Updated mmap patch 29/11/2008
In git some new places use mmap / munmap compared to the old version. This should fix some issues.
http://bugs.winehq.org/show_bug.cgi?id=13335
Michael Jenkins mdjenkins@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mdjenkins@comcast.net
--- Comment #114 from Michael Jenkins mdjenkins@comcast.net 2008-11-29 23:52:05 --- I sure hope I'm following the right bug trail. I started with 15996 which was a dup of 15665 which was also closed as a dup to this one
(In reply to comment #113)
Created an attachment (id=17547)
--> (http://bugs.winehq.org/attachment.cgi?id=17547) [details]
Updated mmap patch 29/11/2008
In git some new places use mmap / munmap compared to the old version. This should fix some issues.
I tried this patch with today's git and 1.1.9. Both times, I recieve no visual output when the 3d engine kicks in for World of Warcraft. Shortly after the game crashes with a this error.
Exception handler died Original exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:7DF205E4 The instruction at "0x7DF205E4" referenced memory at "0xCAD25010". The memory could not be "written".
memory addresses are always the same ~ $ uname -a Linux sparky 2.6.27-gentoo-r4 #4 SMP PREEMPT Thu Nov 27 12:43:40 MST 2008 x86_64 AMD Phenom(tm) 9850 Quad-Core Processor AuthenticAMD GNU/Linux 8gb RAM Dual Nvidia 9600gt SLi - driver: 180.08
http://bugs.winehq.org/show_bug.cgi?id=13335
Nicolay Doytchev lightrush@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|lightrush@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #115 from Xzarr xzarr@lavabit.com 2008-12-05 15:26:12 --- Created an attachment (id=17662) --> (http://bugs.winehq.org/attachment.cgi?id=17662) wine-1.1.10 slow rendering
gcc version 4.3.2 wine-1.1.10 (git Fri Dec 5 21:19:00 GMT 2008) Linux localhost 2.6.26-gentoo-r3 #4 SMP Wed Nov 26 21:56:54 GMT 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux Nvidia 177.82, I have tried 180.11 also same problem.
Warcraft still renders incredibly slowly which I can only assume is from the patch on this page making it into 1.1.10
Not using +relay spits out this in the terminal
err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex sampl
ers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) >
combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f2f0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f658,0x00000000), stub! fixme:dsalsa:IDsDriverBufferImp
l_SetVolumePan (0x13c318,0x13c288): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x13c318,0x13c288): stub fixme:imm:ImmAssociateContextEx (0x3002c, (nil), 16): stub
World of Warcraft also suffers from extremely slow rendering.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #116 from Roderick Colenbrander thunderbird2k@gmx.net 2008-12-06 03:19:00 --- This patch is not inside Wine 1.1.10. If something made your app slow perform a regression test (see wiki.winehq.org on how to do that) and open a new bug for it.
http://bugs.winehq.org/show_bug.cgi?id=13335
Xzarr xzarr@lavabit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xzarr@lavabit.com
--- Comment #117 from Xzarr xzarr@lavabit.com 2008-12-06 13:20:48 --- My mistake, I forgot to change the ebuild so the patch was included, w/o the patch the behaviour is the same as before.
http://bugs.winehq.org/show_bug.cgi?id=13335
Xzarr xzarr@lavabit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17662|wine-1.1.10 slow rendering |wine-1.1.10 with patch, slow description| |rendering
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #118 from Roderick Colenbrander thunderbird2k@gmx.net 2008-12-06 15:33:58 --- So you are saying that the patch causes major performance regressions for you? I talked to an Nvidia guy about the patch and he didn't export performance issues.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #119 from Xzarr xzarr@lavabit.com 2008-12-06 17:58:10 --- (In reply to comment #118)
So you are saying that the patch causes major performance regressions for you? I talked to an Nvidia guy about the patch and he didn't export performance issues.
Yes.
The only way I can play WoW/WC3 currently without it crashing after a short time is using the patch located here http://bugs.winehq.org/show_bug.cgi?id=10778, on an unpatched version of wine I'll get the virtmem error after short time.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #120 from andy-wine@splashground.de 2008-12-07 13:48:11 --- (In reply to comment #116)
This patch is not inside Wine 1.1.10. If something made your app slow perform a regression test (see wiki.winehq.org on how to do that) and open a new bug for it.
Here on Archlinux, x86_64, ATI HD4850, catalyst 8.11, previous version had the libGL error message and everything D3D was slow. With 1.1.10 the message is gone but it is as slow as ever. This is with no patch applied. I'm a bit confused about the people with nvidia cards here, because I thought the problem was ATI only.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #121 from Xzarr xzarr@lavabit.com 2008-12-07 17:24:15 --- (In reply to comment #120)
(In reply to comment #116)
This patch is not inside Wine 1.1.10. If something made your app slow perform a regression test (see wiki.winehq.org on how to do that) and open a new bug for it.
Here on Archlinux, x86_64, ATI HD4850, catalyst 8.11, previous version had the libGL error message and everything D3D was slow. With 1.1.10 the message is gone but it is as slow as ever. This is with no patch applied. I'm a bit confused about the people with nvidia cards here, because I thought the problem was ATI only.
bug 16131 led to bug 10778 which led to here
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #122 from Roderick Colenbrander thunderbird2k@gmx.net 2008-12-08 02:41:58 --- The main issue is lack of virtual memory for native libs. It affects all libraries and video drivers. It is just that fglrx is more sensitive to it and falls backs (or used to fall back) to software rendering when this happened. Nvidia so now and then reports GL_OUT_OF_MEMORY which can be an indication of this problem or in the worst case they crash.
http://bugs.winehq.org/show_bug.cgi?id=13335
Josh Jones joshorjeff@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|joshorjeff@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=13335
Robert Krig rkrig@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rkrig@gmx.de
--- Comment #123 from Robert Krig rkrig@gmx.de 2008-12-22 20:27:23 --- Just wanted to confirm that I'm experiencing reproducable crashes in WoW on the following System:
Gentoo Linux x86_64 Kernel gentoo-sources 2.6.25-gentoo-r7 NVidia 8600GT GPU using nvidia-drivers-177.82 My CPU: Intel Core 2 Quad Q6600 8GB Ram.
Whenever I play, I open up HTOP on my Laptop to track the process. The VIRT column for the WoW.exe process slowly rises during gameplay. Sometimes it falls a little, but whenever the VIRT column gets to 4096M, then WoW crashes shortly thereafter.
From what I've gathered this problem has to do with the way Wine internally
handles memory.
I was just wondering if this is something that can be easily fixed in the short term, or will it require some fundamental changes in the way wine handles memory, which would take quite some time to implement?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #124 from Roderick Colenbrander thunderbird2k@gmx.net 2008-12-23 04:15:10 --- See comment 113 for the fix. We hope to get it cleaned up a bit soon, so that it can enter Wine. Please test it. In short it makes libGL.so and other native apps use memory which was reserved by Wine (Wine only leaves a small amount of VM left to native libs by default in order to emulate the win32 memory layout). This fixes that.
http://bugs.winehq.org/show_bug.cgi?id=13335
haarp liquitsnake@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquitsnake@gmx.net
--- Comment #125 from haarp liquitsnake@gmx.net 2008-12-23 13:17:05 --- Just tried the mmap patch to see if I can fix Crysis' GL_OUT_OF_MEMORY bug. While Vanilla Wine works reasonably, Wine patched with the mmap fix is unbearably slow starting. The menu animation alone takes a few minutes to complete, and it gets worse at higher resolutions. Additionally, a bunch of these appear in the log, which are not there with Vanilla Wine: fixme:d3d:color_fill_fbo >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glClear @ device.c / 6060 OffscreenRenderingMode=fbo was used in both cases. Wine 1.1.11, Nvidia GF8600GT, 173.14.09 drivers
http://bugs.winehq.org/show_bug.cgi?id=13335
Anders Aagaard aagaande@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aagaande@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13335
DL taedium_vitae@eml.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |taedium_vitae@eml.cc
--- Comment #126 from DL taedium_vitae@eml.cc 2008-12-31 19:57:53 --- I've been testing the mmap patch, and it turns out the massive slowdowns only occur when I have 4GB of ram installed in my system.If I physically take 2GB out, the slowdowns don't occur.However, at least in the case of Stalker (with dynamic lighting) and Bioshock, the games still crash with >4000MB VIRT ram.Fallout 3 was more difficult to test, as the game is so crash sensitive even without the MMAP issues, and the mouse patch doesn't seem to be working for me anymore.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #127 from DL taedium_vitae@eml.cc 2008-12-31 20:56:47 --- Okay, I've done some more testing with the mmap patch and using the mem= kernel commanline option.mem=2G results in no slowdowns, as does mem=4G.However mem=4G results in the kernel seeing 3.16GB of ram, not 3.86G which is what the kernel sees with the option off.3.16GB is about the maximum that a 32-bit kernel can address, isn't it, so the issue could be there.I use a x86_64 kernel, though, so it's not a PAE issue.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #128 from Tony Wasserka tony.wasserka@freenet.de 2009-01-01 07:43:53 --- wineserver emulates a 32 bit windows kernel though, which could result in crashes, as the 64 bit Linux actually could allocate more than 3,16GB memory, but the 32 bit Windows kernel can't. Don't know anything about how Wine handles all that, but maybe it has something to do with that :)
http://bugs.winehq.org/show_bug.cgi?id=13335
scy scytheman666@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scytheman666@gmail.com
--- Comment #129 from scy scytheman666@gmail.com 2009-01-16 16:33:46 --- With Wine 1.1.13 "libGL error: drmMap of framebuffer failed" error disappeared. fps when playing warcraft3 are pretty good.(~70fps, with wine-1.1.12 ~20fps) no lagg anymore.
thanks for fixing this issue. :)
These are the messages i receive now, when starting warcraft3:
"err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 16 vertex samplers and 16 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f2f0,0x00000000), stub! fixme:d3d:test_pbo_functionality >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Loading the PBO test texture @ directx.c / 3817 fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 16 vertex samplers and 16 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f6c4,0x00000000), stub! fixme:d3d:test_pbo_functionality >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Loading the PBO test texture @ directx.c / 3817 fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 16 vertex samplers and 16 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f2d0,0x00000000), stub! fixme:d3d:test_pbo_functionality >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Loading the PBO test texture @ directx.c / 3817 fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface"
with: ATI HD3870 on gentoo amd64: kernel 2.6.27 fglrx 8.12 xorg-x11 7.4
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #130 from Roderick Colenbrander thunderbird2k@gmx.net 2009-01-17 04:01:30 --- Are you sure it is something in Wine which fixed it for you instead of a ati driver update? As we haven't changed anything in this area.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #131 from scy scytheman666@gmail.com 2009-01-17 04:13:29 --- this could be possible, too. i've updated ati-drivers from 8.10 -> 8.12, xorg from 7.2 to 7.4 wine from 1.1.12 -> 1.1.13 at the same time. i will try if using an older wine version will fix this issue, too.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #132 from Seppo Yli-Olli seppo.yli-olli@iki.fi 2009-01-17 05:49:46 --- (In reply to comment #128)
wineserver emulates a 32 bit windows kernel though, which could result in crashes, as the 64 bit Linux actually could allocate more than 3,16GB memory, but the 32 bit Windows kernel can't. Don't know anything about how Wine handles all that, but maybe it has something to do with that :)
An educated guess is that as Wine is compiled as not 64-bit aware (that is, just like any other program that is explicitly compiled as 32-bit), it is therefore limited by the 32-bit memory limitations just as much as it would be on a 32-bit Linux. If there's a problem with memory handling, it should be a Linux vs Windows memory handling problem instead of a 32-bit vs 64-bit memory handling one.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #133 from Roderick Colenbrander thunderbird2k@gmx.net 2009-01-17 06:49:26 --- This bug is not essentially 64-bit related at all. In order to run 32-bit apps Wine is ALWAYS 32-bit, it is also not really related to the amount of physical memory in the system, this is about virtual memory which is 4GB on a 32-bit system. Read up on wikipedia about virtual memory if you want to know what it is. This bug is a Wine bug in which we don't leave enough 'linux' virtual memory around. the proposed patch makes win32 apps use 'win32' memory.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #134 from Michael Jenkins mdjenkins@comcast.net 2009-01-20 09:22:58 --- While it isn't specifically a 64-bit issue there does appear to me to be two parts to this bug. The first part being that wine reserves large amounts of virtual memory that eventually starves the opengl engine of resource. The second part being how virtual memory is allocated when greater than 4G of RAM exists (which exists only in a 64-bit environment).
System spec: Asus M3N-HT Phenom 9850 8gb RAM
Without the patch the out of memory error is frequent and random. With the hack patch from bug 10778 applied; I can play for hours with gradual slowdown. With this patch applied; the memory error occurs the moment the OpenGL engine kicks in. With this patch applied and mem=4G passed to the kernel on boot; I can play WoW for hours without issue.
When swapping out my CPU with a Phenom II 940 (remember AMD puts the memory controller on die).
Without the patch the out of memory error is frequent and random. With the hack patch from bug 10778 applied; the out of memory error is frequent and random. With this patch applied; the memory error occurs the moment the OpenGL engine kicks in. With this patch applied and mem=4G passed to the kernel; on boot I can play WoW for hours without issue.
Hope this helps.
http://bugs.winehq.org/show_bug.cgi?id=13335
Patrick Goldmann scape@bawue.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scape@bawue.net
--- Comment #135 from Patrick Goldmann scape@bawue.net 2009-02-13 10:50:05 --- (In reply to comment #134)
Without the patch the out of memory error is frequent and random. With the hack patch from bug 10778 applied; I can play for hours with gradual slowdown. With this patch applied; the memory error occurs the moment the OpenGL engine kicks in. With this patch applied and mem=4G passed to the kernel on boot; I can play WoW for hours without issue.
Confirmed, my wine installation behaves almost the same way. Patched latest git with updated mmap patch and rebooted with mem=4G option. Everything works smoothly now. Kinda sucks though if i can't use all the memory my system has :(
On a sidenote: the patch didn't apply cleanly to current git, but just one include was rejected, so i inserted it manually.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #136 from Lee Standen nom@standen.id.au 2009-03-13 11:00:13 --- Created an attachment (id=19905) --> (http://bugs.winehq.org/attachment.cgi?id=19905) Patch for this issue on wine 1.1.15
http://bugs.winehq.org/show_bug.cgi?id=13335
Lee Standen nom@standen.id.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nom@standen.id.au
--- Comment #137 from Lee Standen nom@standen.id.au 2009-03-13 11:01:41 --- Special tanks Roderick.
I have adapted his patch and made it work for wine 1.1.15 - this appears to have completely resolved the problem for me on a Fedora 10 x86_64 system. I do have the mem=4G kernel option on, but I shall be trying without it very shortly.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #138 from Lee Standen nom@standen.id.au 2009-03-13 14:23:35 --- http://bugs.winehq.org/attachment.cgi?id=19905
The above patch is just a modified version of http://bugs.winehq.org/attachment.cgi?id=17538
It does fix the problem, however without the mem=4G kernel option, World of Warcraft was loading in a hidden way. I could see the process, and hear the background noises on the login screen, but I could not get the thing to show up.
Anyway, I'm happy for now, so I'll leave it to someone more capable to fix it up so I can remove the mem=4G kernel option... I like extra memory :)
http://bugs.winehq.org/show_bug.cgi?id=13335
Dennis Hedegaard neo2k@neo2k.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |neo2k@neo2k.dk
--- Comment #139 from Dennis Hedegaard neo2k@neo2k.dk 2009-03-15 12:08:57 --- wine 1.1.17 introduced some changes to the loader, so the patch for 1.1.15 does not patch very well. Any chance that someone with the knowledge needed could update it ?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Adys adys.wh+winehqdotorg@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
http://bugs.winehq.org/show_bug.cgi?id=13335
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tony.wasserka@freenet.de |
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
Brian Rogers brian@xyzw.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian@xyzw.org
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com Attachment #20401|0 |1 is obsolete| |
Myk Taylor myk002@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |myk002@yahoo.com
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
handsomepete jeff.mitchell+WINE@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff.mitchell+WINE@gmail.co | |m
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|libGL error when launching |Wine virtual memory |warcraft 3 |exhaustion causing OpenGL | |crashes / slowdowns
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
Frederic kaempfer@mathematik.uni-marburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaempfer@mathematik.uni-mar | |burg.de
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
tedem82 tedem82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tedem82@hotmail.com
Christian Weeks cpw@weeksfamily.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cpw@weeksfamily.ca
Albert Lee trisk-winehq@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk-winehq@forkgnu.org
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |loader CC| |damron@mytech.wvutech.edu
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
zitzengallenfliege@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zitzengallenfliege@hotmail. | |com
Pavel Ondracka drakkk@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |drakkk@centrum.cz
Gellule Xg gellule.xg@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gellule.xg@free.fr
Florian Klink flokli@flokli.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |flokli@flokli.de
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED Status|RESOLVED |CLOSED
Daniel Spies daniel.spies@fuceekay.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.spies@fuceekay.com
maniac jedimastermaniac@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jedimastermaniac@hotmail.co | |m
--- Comment #140 from François Gouget fgouget@codeweavers.com 2009-03-25 04:49:06 --- Created an attachment (id=20117) --> (http://bugs.winehq.org/attachment.cgi?id=20117) Test application
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
--- Comment #141 from Rico kgbricola@web.de 2009-03-27 06:46:08 --- Created an attachment (id=20139) --> (http://bugs.winehq.org/attachment.cgi?id=20139) Results of the test application for different plattforms (linux{32,32pae,64})
Attached is the result for the test application for different linux versions (32Bit, 32Bit+pae, 64Bit, +wine).
The result is that wine shows on all tested linux platforms the same behaviour. This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and shows that this hasn't any influence on the tested platforms which wine is used on.
--- Comment #142 from Rico kgbricola@web.de 2009-04-02 14:31:39 ---
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.
Your test app doesn't trigger any call to mmap (with modified mmap patch). So the result is identical to my previous test. Could anyone confirm that?
--- Comment #143 from Rico kgbricola@web.de 2009-04-03 13:44:51 --- Created an attachment (id=20275) --> (http://bugs.winehq.org/attachment.cgi?id=20275) Test results with wglgears on wine on different linux versions (32Bit, 32Bit+pae, 64Bit, 64Bit+mem4g)
This test addresses the speed problem on several machines.
Attached is the test run of wglgears on wine on different linux kernels with a nvidia graphics card. The result is that in every frame on a clean 64Bit system there are 3 additional mmap/munmap calls which aren't there in any other run (32bit,32bitpae,64bitmem4g).
Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who could run the test?
--- Comment #144 from Rico kgbricola@web.de 2009-04-10 11:45:56 --- Created an attachment (id=20366) --> (http://bugs.winehq.org/attachment.cgi?id=20366) wglgears debug output on 64bit with original mmap and virtual mmap wrapper
I've done some further testing with the slowness on a nvidia gpu and >4gb ram on 64bit. I've added some debug output to the patch. Also, I checked the test on an ati x800 with fglrx on the same machine and there was no slowdown.
The file names have this meanings: 64bit - linux 64bit kernel mem4g - kernel option mem=4g was used orig - original mmap was taken slow - the new mmap (virtual_mmap_wrapper) was taken
Result: The logs 64bit_mmap_slow.log and 64bitmem4g_mmap_slow.log differ at line 178. And there the nvidia driver couldn't get memory, which probably leads to a slow rendering path. Also note that the run on 64bit with mem=4g option isn't slow! Probably I should have given it another name ...
Test system: geforce 8800gts, nvidia driver 185.19, kernel 2.6.27.21-170.2.56.fc10.x86_64
--- Comment #145 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:07:26 --- Created an attachment (id=20401) --> (http://bugs.winehq.org/attachment.cgi?id=20401) Forward port of proposed patch to 1.1.19
I've ported and hopefully fixed-up the patch from 1.1.15 (attachment 19905) for 1.1.19 (current HEAD).
Because wine_pthread_callbacks and related code went away, the code's shorter but slightly ass. The main ass thing is that the mmap wrappers are now calling wine_pthread_get_functions every time, because they need to get the changed mmap redirections once ntdll's virtual.c has applied them, but there's no other signalling system in place for libwine's code (which receives the changed mmap redirections) to tell the loader to use them.
Moving the mmap wrappers to libwine would fix this, but then the mmap wrappers don't override the libc functions as libwine is loaded after libc. It might be possible to get around that by redirecting the loader mmap wrappers back into libwine. I'm not sure that's a lot less ass, but it might be faster, and would fix the slight chance that exit_thread calls the wrong munmap.
Anyway, on my 4gB x86_64 system with nVidia 8600M running driver 180.29, this patch causes Warhammer Online to not crash due to an OUT_OF_MEMORY error from OpenGL, and the test application attached here goes from allocating 480MB to 4040MB or 4050MB compiled as a Winelib application (mmap 10 500). For comparison, native 32-bit build of the test app produces 4070MB, and 64-bit build (printfs needed fixing, will attach modified source later) happily allocations 5000MB (ie. everything asked for) in the mmap 10 500 test.
--- Comment #146 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 13:12:42 --- Created an attachment (id=20402) --> (http://bugs.winehq.org/attachment.cgi?id=20402) François Gouget's test application, 64-bit clean
64-bit clean version of the test application.
--- Comment #147 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 20:10:45 --- It's been pointed out to me on IRC that the patch doesn't fix the malloc case in the test application, presumably because glibc's malloc doesn't call glibc's mmap wrapper code directly, or at least not in a way we can intercept.
So if we need to fix malloc as well as mmap, then we need to redirect malloc to HeapAlloc or something...
--- Comment #148 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:32:58 --- I've knocked up a quick malloc/calloc/free/realloc passthrough (that does't redirect to HeapAlloc, just passes straight on to the RTLD_NEXT function) and it seems to cause the test app to lock up.
However, redirecting malloc won't capture, for example, a library that uses C++ internally (as the C++ allocator is not required to use malloc internally) anyway.
On examination, libc's internal malloc appears to be calling the mmap2 system call.
Anyway, I think overriding malloc should be addressed with a separate patch, since the mmap patch is sufficient to fix the GL memory exhaustion failures this bug was submitted for, and libraries are likely to malloc much smaller amounts of memory than they're willing to mmap...
--- Comment #149 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-12 22:46:12 --- A quick note, electric-fence or duma are examples of things that override malloc.
Duma overrides: void * malloc(size_t size) void * calloc(size_t nelem, size_t elsize) void free(void * address) void * memalign(size_t alignment, size_t size) int posix_memalign(void **memptr, size_t alignment, size_t size) void * realloc(void * oldBuffer, size_t newSize) void * valloc(size_t size) char * strdup(const char * str) void * memcpy(void *dest, const void *src, size_t size) char * strcpy(char *dest, const char *src) char * strncpy(char *dest, const char *src, size_t size) char * strcat(char *dest, const char *src) char * strncat(char *dest, const char *src, size_t size)
--- Comment #150 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-13 11:34:42 --- Just a quick note, I've confirmed from looking at the disassembly of both 32-bit and 64-bit libc6 on Debian/unstable (glibc 2.9) that malloc there calls glibc's mmmap methods directly, not via the plt (compared to strdup calling malloc via the plt for example, so it uses an overridden malloc)
So the original intent of the patch to fix malloc by replacing mmap isn't portable, so if malloc needs fixing, malloc and friends need wrapping.
--- Comment #151 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 08:58:34 --- Created an attachment (id=20483) --> (http://bugs.winehq.org/attachment.cgi?id=20483) Forward port of proposed patch to 1.1.19
Slight update to mmap redirection patch, to only call wine_pthread_get_functions when it is safe to do so, ie. we've finished our dlsyming.
--- Comment #152 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-04-16 09:07:09 --- Created an attachment (id=20484) --> (http://bugs.winehq.org/attachment.cgi?id=20484) Redirect malloc to Win32 Heap
This is a redirection of malloc along the lines of attachment 20483 and its predecessors into the Win32 Heap.
It makes memtest (attachment 20402) able to malloc 2gB with the 500 x 10MB test up from 480MB.
Structurally, it's not spectacular. The redirects don't really belong in ntdll/virtual.c that I can see, they are only there because I don't want to add another caller of wine_set_pthread_functions unless it's the earliest point there GetProcessHeap() becomes valid.
And the calling of wine_get_pthread_functions in the mmap and malloc override sets is nasty, but works.
The disadvantage of this patch mainly is that instead of having a 500MB address space for POSIX malloc and a 2gB address space for Win32 HeapAllocate, POSIX malloc and Win32 HeapAllocate share a 2gB address space. More space for POSIX, less total address space.
This could be alleviated by only redirecting POSIX when out of POSIX address space, I guess.
At this point, I don't know that this change is even neccessary, we're not seeing POSIX address space exhaustion due to malloc, that I am aware of or can replicate except in memtest. ^_^
Anyway, this is more of a proof-of-concept/hammer-upon patch, free free to take it and mangle it into shape. You may add
Thrown-Together-In-An-Evening: Paul "TBBle" Hampson Paul.Hampson@Pobox.com
or similar if you wish. ^_^
--- Comment #153 from DL taedium_vitae@eml.cc 2009-04-16 22:37:34 --- Just tested the latest mmap and malloc patch.When both are applied to 1.1.19, stalker and bioshock no longer crash immediately at specific points of each game.Without the malloc patch applied, these crashes still occur, so the malloc patch certainly seems to be necessary.These 2 patches seem to work at least as well as the preloader hack.I'll have to to play a long session to see if any crashes occur, as this was where the games would eventually crash with the preloader hack.
--- Comment #154 from Myk Taylor myk002@yahoo.com 2009-04-17 07:29:24 --- As a side note, this also seems to fix out of memory errors in Oblivion.
--- Comment #155 from dlzerocool dl.zerocool@gmail.com 2009-04-26 01:54:18 --- (In reply to comment #152) I patched with both mmap and malloc patch. Before I was getting Warhammer Online to Kill my X server after "X"minutes when playing, it has fully disapear.
I got one crash and get back to desktop, but this is not "our" wine fault, Warhammer Online do it already in windows, the client is not "very" stable.
So your patch greatly improved this. Thanks.
--- Comment #156 from handsomepete jeff.mitchell+WINE@gmail.com 2009-05-05 06:50:35 --- These patches so far have improved my stability in City of Heroes quite a bit. Before I would crash after changing zones 3 or 4 times, but since applying these I haven't crashed yet. Hope they can find their way into wine permanently some way or another.
--- Comment #157 from Roderick Colenbrander thunderbird2k@gmail.com 2009-05-05 09:06:59 --- Updating title to better reflect the real problem.
--- Comment #158 from Jeff Zaroyko jeffz@jeffz.name 2009-05-06 22:22:04 --- *** Bug 17655 has been marked as a duplicate of this bug. ***
--- Comment #159 from John P Sims jsims2359@gmail.com 2009-05-16 02:54:55 --- I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
--- Comment #160 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 08:59:57 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
--- Comment #161 from Frederic kaempfer@mathematik.uni-marburg.de 2009-05-17 09:08:52 --- (In reply to comment #160)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
Can you tell me the exact patches you used for 1.1.21 ? I tried Redirect malloc to Win32 Heap and Updated mmap patch 29/11/2008 but they seem to fail for some reason. Thanks
Nevermind. The patches from comment #152 seem to work just fine.
--- Comment #162 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-18 01:58:56 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
I cannot confirm that. I just patched Wine 1.1.21 with (and only with these patches)
Redirect malloc to Win32 Heap Forward port of proposed patch to 1.1.19
and i get more often (almost everytime) errors than without these patches:
wine: Unhandled page fault on write access to 0x00000005 at address 0x7bc43bb4 (thread 0024), starting debugger...
or
segmentations fault
Preloader hack fixes it for me.
My specs are:
gfx 9xxx ram 4GB os: Fedora 32 bit (kernel is PAE so it uses all 4 GB)
--- Comment #163 from tedem82 tedem82@hotmail.com 2009-05-24 14:39:08 --- (In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
--- Comment #164 from Jerome Leclanche adys.wh@gmail.com 2009-05-24 14:55:12 --- (In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
--- Comment #165 from tedem82 tedem82@hotmail.com 2009-05-24 16:10:05 --- (In reply to comment #164)
(In reply to comment #163)
(In reply to comment #159)
I patched wine-1.1.21 with both mmap and malloc patches. I just finished 5 hours of "testing" bioshock and I can report that there were no crashes. Well done!
hello, i've tried to apply these patches, with this sort of command : " patch -p0 < mmap.patch "
but i have to answer this question : " File to patch : "
so, what do i have to make ?
PS: sorry for my english, i'm french.
Use -p1.
i tried and here is the result (failed) :
teddy@tedportable:~/wine/wine-1.1.18$ patch -p1 < mmap.patch patching file dlls/ntdll/ntdll_misc.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/ntdll_misc.h.rej can't find file to patch at input line 34 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/pthread.c b/dlls/ntdll/pthread.c |index 60b6033..e2c3aa6 100644 |--- a/dlls/ntdll/pthread.c |+++ b/dlls/ntdll/pthread.c -------------------------- File to patch: Skip this patch? [y] n File to patch: pthread.c pthread.c: No such file or directory Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 53. Hunk #2 succeeded at 149 (offset 1 line). Hunk #3 succeeded at 362 (offset 1 line). Hunk #4 succeeded at 389 (offset 1 line). 1 out of 10 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej patching file include/wine/pthread.h Hunk #1 FAILED at 77. Hunk #2 succeeded at 61 (offset -51 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/wine/pthread.h.rej patching file libs/wine/mmap.c patching file libs/wine/port.c can't find file to patch at input line 519 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/loader/kthread.c b/loader/kthread.c |index c791ef6..3d62ddf 100644 |--- a/loader/kthread.c |+++ b/loader/kthread.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored patching file loader/pthread.c Hunk #1 succeeded at 63 with fuzz 1 (offset 11 lines). Hunk #2 succeeded at 73 (offset 11 lines). Hunk #3 succeeded at 213 (offset 22 lines). Hunk #4 succeeded at 272 (offset 22 lines). Hunk #5 succeeded at 281 (offset 22 lines).
so, what do i have to make please ?
--- Comment #166 from NSLW lukasz.wojnilowicz@gmail.com 2009-05-24 16:20:35 --- (In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
--- Comment #167 from tedem82 tedem82@hotmail.com 2009-05-24 17:32:14 --- (In reply to comment #166)
(In reply to comment #165) Please don't ask here how to compile or what to do when it's not compiling because this isn't the right place to do this (this is not forum). You are making unneeded noise and disturbing to resolve the bug thus stoping Wine development.
Please go to http://forum.winehq.org/ and ask there.
sorry, i don't do it anymore.
--- Comment #168 from André H. nerv@dawncrow.de 2009-05-25 07:15:17 --- Created an attachment (id=21303) --> (http://bugs.winehq.org/attachment.cgi?id=21303) wine64-1.1.22 build of testcase
the wine64 build got less problems with malloc and no problems with mmap.
--- Comment #169 from Christian Weeks cpw@weeksfamily.ca 2009-05-25 10:49:55 --- I would like to just add that the two patches (20484 and 20483) applied (almost- 1 line was offset) cleanly to my wine 1.1.22 git download, and they appear to have resolved this error in my environment.
Further testing when I get to raid, but all the common ways to reproduce the crash (flying around outside dalaran, zoning into dalaran, basically whenever I quickly have a large vertex delta seems to be the best way to reproduce) haven't occured with these two patches applied. Additionally, I notice about a 33% improvement in performance (was ~10-17fps in dalaran when busy, noticed ~20-30fps in dalaran last night when busy!).
Environment: debian sid amd64. 8G ram. GTX260 Nvidia w/180.60 driver version. Wine built from git download with the two patches applied.
Hope this helps.
--- Comment #170 from Albert Lee trisk-winehq@forkgnu.org 2009-06-01 22:23:13 --- Created an attachment (id=21492) --> (http://bugs.winehq.org/attachment.cgi?id=21492) Refactored virtual mmap wrapper - 20090601
here is a refactored version of the mmap wrapper implementation in attachment 20483. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
The addition to init_virtual() fixes a problem still present in the previous patch where the orig_mmap function pointers were being assigned too late.
I haven't yet looked at the malloc wrapper or the testcase (yeah yeah).
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
ntdll/ntdll_misc.h: extern void virtual_init_mmap(void);
--- Comment #171 from Jeff Zaroyko jeffz@jeffz.name 2009-06-04 18:10:22 --- *** Bug 18706 has been marked as a duplicate of this bug. ***
--- Comment #172 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 09:43:36 --- (In reply to comment #170)
here is a refactored version of the mmap wrapper implementation in attachment 20483 [details]. It seperates the mmap function mapping from the pthread code and avoids having multiple copies of the function pointers scattered around.
The header changes in this version: wine/library.h: extern void *(*wine_mmap)( void *addr, size_t size, int prot, int flags, int fd, off64_t offset ); extern int (*wine_munmap)( void *addr, size_t size );
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
--- Comment #173 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-06 10:57:37 --- (In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
--- Comment #174 from Albert Lee trisk-winehq@forkgnu.org 2009-06-13 03:28:14 --- (In reply to comment #172)
This seems to break on 32-bit systems (or at least one, reported on IRC) I believe because "_FILE_OFFSET_BITS 64" is set in include/wine/port.h but include/wine/library.h doesn't include that file, and presumably is included somewhere that include/wine/port.h isn't.
dlls/winecrt0/dll_entry.c is one such somewhere.
Hm, it's not clear to me why this is causing problems since the wine_mmap functions (and the underlying virtual functions) have fixed signatures and so shouldn't be subject to off_t changing size.
(In reply to comment #173)
(In reply to comment #170)
Created an attachment (id=21492)
--> (http://bugs.winehq.org/attachment.cgi?id=21492) [details] [details]
Refactored virtual mmap wrapper - 20090601
The overrides now allow mmap to be a macro (and has alternative function signatures for Solaris) and should be 64-bit safe.
I'm not clear on why you've arranged the code the way you have for this. Particularly, why the mmap_override stuff? Simply not defining mmap64 on a 64-bit build (is there already a macro in Wine for knowing we're building 64-bit? _LP64 isn't used anywhere in the current codebase) would achieve what you're trying to achieve, without needing to dance around the function names with other macros. Although I don't think there's any harm in having mmap64 on 64-bit systems, at least for glibc6 mmap64 is an internal implementation detail of mmap when 64-bit file offsets are enabled.
The reasons for the mmap_override #defines were: * mmap could be a macro (e.g. #define mmap mmap64) * The function signature of mmap would match mmap64 in a 64-bit build
Since the mmap override currently has a long type for the offset, I agree that the _LP64 case should be unnecessary. An alternative solution for the first problem would be to #undef mmap, of course.
I'm also a little unclear on the __PRAGMA_REDEFINE_EXTNAME bit. That indicates to me that on a 64-bit build under Solaris, no mmap method will be defined.
The redefine_extname pragma is used in Solaris' sys/mman.h to convert all references to "mmap" in the symbol table to "mmap64". Thus the "mmap" definition actually results in a duplicate for "mmap64". I've tried using the pragma to rename the mmap_override functions but have not been successful, hence the FIXME.
--- Comment #175 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-13 09:54:15 --- Marking this bug as a loader bug instead of a opengl one because it is a general wine bug which affects all native libraries.
--- Comment #176 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- *** Bug 16456 has been marked as a duplicate of this bug. ***
--- Comment #177 from Robert Andersson roband@pobox.com 2009-06-22 03:06:02 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
In opengl mode the error takes some time to develop, in D3D mode the error comes much faster.
Do a bugzilla search for "out of memory" and you'll see it's likely this bug affects a whole bunch of different games using high-end graphics.
--- Comment #178 from Alexandre Julliard julliard@winehq.org 2009-06-25 09:50:06 --- 09712593c8496be5e952b7316099f9eed5043203 should help. Please retest with current git.
--- Comment #179 from zitzengallenfliege@hotmail.com 2009-06-25 12:58:16 --- (In reply to comment #178)
09712593c8496be5e952b7316099f9eed5043203 should help. Please retest with current git.
Seems to work much better now. I'm playing World Of Warcraft with Fedora 11 64-Bit. No crashes so far. I'll keep testing.
--- Comment #180 from Pavel Ondracka drakkk@centrum.cz 2009-06-25 13:16:32 --- I can confirm that, no crash so far in Sins of a Solar Empire, Fedora 11, 64-Bit. However, I haven't tested longer gameplay (3+ hours) yet.
--- Comment #181 from Gellule Xg gellule.xg@free.fr 2009-06-26 23:55:38 --- Much better for Ryzom under linux Ubuntu 9.04 on a Mac Book. A new issue for the same Ryzom under OS X on the same Mac Book. See: http://bugs.winehq.org/show_bug.cgi?id=19094
--- Comment #182 from Florian Klink flokli@flokli.de 2009-06-27 15:58:55 --- works for me too. thanks!
--- Comment #183 from Gellule Xg gellule.xg@free.fr 2009-06-30 01:54:23 --- With this one fixed: http://bugs.winehq.org/show_bug.cgi?id=19094 Much better with Ryzom under OS X on a Mac Book. All graphical options turned to the max and the game does not crash for me. Very nice!
--- Comment #184 from Alexandre Julliard julliard@winehq.org 2009-06-30 12:02:41 --- Marking fixed then.
--- Comment #185 from Alexandre Julliard julliard@winehq.org 2009-07-03 12:14:14 --- Closing bugs fixed in 1.1.25.
--- Comment #186 from maniac jedimastermaniac@hotmail.com 2009-10-20 12:32:51 --- In Age of Conan it's reported that this bug still persists according to the latest test data ttp://bugs.winehq.org/show_bug.cgi?id=13335 Old comments clean up comment
http://bugs.winehq.org/show_bug.cgi?id=13335
Macie macie@linuxfusion.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |macie@linuxfusion.net
--- Comment #187 from Macie macie@linuxfusion.net 2009-11-02 09:40:50 --- This bug still exists, using latest git
wine-1.1.32-260-gf222a16 Fedora 11 64bit + all updates i7 920 12GB Ram Nvidia GTX 295 1792MB (185.18.36 driver)
Once virtual memory for the game process reaches little over 4000mb the game crashes. Passing mem=4g makes the game behave normally, but that's just temp solution since it completely defeats the purpose of having a 4g+ system.
Feel free to let me know if there is any additional info I can provide.
http://bugs.winehq.org/show_bug.cgi?id=13335
paulo i30817@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |i30817@gmail.com
--- Comment #188 from paulo i30817@gmail.com 2010-02-26 22:34:14 --- Obviously not fixed. Seeing something extremely similar with git built 1.2 and vampire bloodlines.
Actually it was working (until starting the main game crashes the graphic driver) with the default ubuntu repositories but i enabled the wine repositories and it stopped entering the menu with a oom.
Tried bisecting, but it seems that all versions 1.1.34 - 1.1.39 have the bug so probably does ubuntu apply this patch to their wine version?
http://bugs.winehq.org/show_bug.cgi?id=13335
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #189 from Jörg Höhle hoehle@users.sourceforge.net 2010-05-13 14:39:57 --- Here's another data point: mmap failures on 32bit Mac OS X 10.5.8 + NVidia with wine-1.1.24
After upgrading my Mac from 1GB RAM to 4GB, Lego Star Wars 2 started crashing in Wine-1.1.24 after a variable amount of play time. The error always starts with:
wine(6017,0xa022e720) malloc: *** mmap(size=16777216) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug
This is repeated 6/8/10 times, size always 16MB, followed by a crash like: wine: Unhandled page fault on write access to 0x0000003c at address 0x7305cadb (thread 0018), starting debugger... The backtrace shows nothing particular.
The machine is an "early 2009" Mac mini 2GHz core duo with Nvidia 9400 graphics processor. Using Mac OS X 10.5.8 and XQuartz 2.3.3.2. So this is a strict 32bit system.
The crashes occur sometimes after half an hour, sometime after an hour of game play. I'm pretty confident that the RAM upgrade is the cause because - no SW upgrade of any kind was done around that time (let's hope I got no trojan), - I'm using LSW2 in wine-1.1.24 with a prefix distinct from my git snapshot work, - the app has been very stable in the past (the children played for hours), - another app started failing as well (see next comment), - the crashes appear in levels the children played in the past, not new ones, - such a huge RAM upgrade affects the memory mapping. Among others, the Nidia chip is said to make use of more main memory when the machine has more than 1GB RAM (256MB? instead of 128MB).
Obviously the machine is not running out of memory. It now has more than before. Instead, I believe this confirs the hypothesis about running out of address space, c.f. R. Colenbrander's comment #96.
I have no reasons to believe that the new RAM is faulty. The machine is very stable and only 2 apps in Wine are affected. I'm not going to remove the RAM because of the effort it was to open the Mac mini box (the back sat so tight that you couldn't slide in a putty knife, not even a sheet of paper).
Perhaps somebody knows a SW tool that can simulate a Mac equipped with 1GB RAM only?
Few people ever reported the dependency of the mmap failure on the amount of RAM. http://forums.adobe.com/message/1875853 mentions a perhaps similar failure with native Photoshop.
Because of bug #22029 I cannot test the app in current Wine. It's unfortunate that this mmap issue affects wine-1.1.24 because this release was excellent at 3D games with the 1GB Mac Mini.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #190 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-13 14:53:05 --- You could try to work around bug 22029 if you set the OffscreenRenderingMode (see http://wiki.winehq.org/UsefulRegistryKeys) to backbuffer. Hopefully the game works then. You might encounter some rendering issues but perhaps you can reproduce the issue.
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #191 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-13 14:54:49 --- One minor thing perhaps it is better to continue this in a new bug report ;) This bug was officially for Linux. We do have a similar bug for Solaris which also has its own bug id.
http://bugs.winehq.org/show_bug.cgi?id=13335
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|lukasz.wojnilowicz@gmail.co | |m |
http://bugs.winehq.org/show_bug.cgi?id=13335
Devin Cofer ranguvar@archlinux.us changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ranguvar@archlinux.us
--- Comment #192 from Devin Cofer ranguvar@archlinux.us 2010-11-07 00:19:16 CDT --- Still an issue for me (6GiB system RAM, x86_64 Linux OS, NVIDIA driver, World of Warcraft specifically).
Patch at http://www.startux.de/index.php/articles/51-wine-patch-to-use-3gb-userspace fixes the problem for me so far (not suggesting it for merge, I know it's nearly definitely not an acceptable solution).
http://www.limitlessfx.com/wine-world-of-warcraft-crash-4gb.html , though I haven't tried it yet, is probably a 100% solid solution for anyone having this issue with any application (not just WoW).
http://bugs.winehq.org/show_bug.cgi?id=13335
Ivanov d137@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d137@abv.bg
--- Comment #193 from Ivanov d137@abv.bg 2011-07-03 12:45:48 CDT --- Could you please rebase the patch for 1.3.23?
http://bugs.winehq.org/show_bug.cgi?id=13335
paulo i30817@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|i30817@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=13335
Stefan Reimer it@stefanreimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |it@stefanreimer.de
--- Comment #194 from Stefan Reimer it@stefanreimer.de 2011-11-20 14:36:22 CST --- (In reply to comment #193)
Could you please rebase the patch for 1.3.23?
Rebased vs 1.3.33
Amazed that this little hack is still useful :D
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #195 from Damian Ivanov damianatorrpm@gmail.com 2012-06-26 02:20:28 CDT --- Is this still an issue in 1.5.6 or newer?
http://bugs.winehq.org/show_bug.cgi?id=13335
--- Comment #196 from Robert Andersson roband@pobox.com 2012-06-26 11:34:04 CDT --- Yes, it still happens after for instance playing World of Warcraft for hours in row involving lots of zone changes etc.
But since this bug is closed, no point commenting here, open a new bug if needed.
https://bugs.winehq.org/show_bug.cgi?id=13335
Manoa manoa@manoa.dream.org.il changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |manoa@manoa.dream.org.il
--- Comment #197 from Manoa manoa@manoa.dream.org.il --- you wine devs are really full of shit, you "CLOSED FIXED" whatever the f you want doing nothing to really fix the problem, I test a zillion games every year on every major version you make and NOT ONCE OR EVER this problem was remotely "FIXED", I will tell you what is "CLOSED FIXED": your ass
don't wanne fix it, fine I don't ask you to, have at least the decency to admit you fix nothing, you make me vomit.
-
wine-bugs＠winehq.org