[Bug 21962] New: Call of duty 4 regression

http://bugs.winehq.org/show_bug.cgi?id=21962

Summary: Call of duty 4 regression
           Product: Wine
           Version: 1.1.38
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]

Created an attachment (id=26669)
 --> (http://bugs.winehq.org/attachment.cgi?id=26669)
log trace generated by the game's last crash

Call of duty 4 crashes while running, with wine-1.1.38.

My regression test gives me :
224043d6cf8b56e9ff2537358646700211d54d1f is first bad commit
commit 224043d6cf8b56e9ff2537358646700211d54d1f
Author: Stefan Dösinger 
Date:   Thu Jan 28 20:51:06 2010 +0100

wined3d: Implement dynamic buffers with GL_ARB_map_buffer_range.

I checked that the crash happens also with v1.1.39 and v1.1.40.
Attached is the trace generated when the game crashes.

For now, i'll stick with v1.1.37...

Thanks for your support,
Seb.

[Bug 21962] Call of duty 4 regression

http://bugs.winehq.org/show_bug.cgi?id=21962

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Austin English   2010-03-07 12:20:01 ---
Dupe.

*** This bug has been marked as a duplicate of bug 21707 ***

[Bug 21962] Call of duty 4 regression

http://bugs.winehq.org/show_bug.cgi?id=21962

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Vitaliy Margolen   2010-03-07 17:21:38 ---
Closing

[Bug 21962] Call of duty 4 regression

http://bugs.winehq.org/show_bug.cgi?id=21962

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|DUPLICATE                   |

--- Comment #3 from Austin English   2010-03-09 15:03:22 ---
According to Stefan, not a dupe of bug 21707 (see that bug's comments).

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Jeff Zaroyko  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Call of duty 4 regression   |Call of Duty 4 crashes

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Jeff Zaroyko  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #4 from Stefan Dösinger   2010-03-10 03:05:57 ---
Can you attach a +d3d,+tid log?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #5 from Stefan Dösinger   2010-03-10 13:50:51 ---
Hi,
I attached a debug patch to bug 21941. Can you give it a try? If CoD 4 suffers
from the same problem I suspect in Alpha Prime then it should still crash. If
it works then there's some other issue.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #6 from Sébastien Fiévet   2010-03-12 03:41:54 ---
(In reply to comment #5)

Hello Stephan,

thank you for your support... and I apologize for the delay of my reply.
Prior to testing your patch related to bug 21941, i generated the bug report
with +d3d,+tid. My concern is the file size being 2.3Go... Do you need the
whole log, 
or say, the last 10% (or even less)? I'll test your patch tonight.

BTW, it takes like 1-2 minutes of gameplay to trigger the crash. It doesn't
happens at the very start of a game.

Regards, Seb.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #7 from Stefan Dösinger   2010-03-12 11:40:17 ---
This sounds as if its related to the alignment of the returned pointers - Most
pointers the nvidia driver returns are properly aligned, so it will take a
while before you hit a non-aligned one.

Can you monitor bug 21941? I'll attach more test patches there, but I don't
want to close your bug as a duplicate again just yet.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #8 from Sébastien Fiévet   2010-03-12 16:49:07 ---
(In reply to comment #7)
I applied your patchset against today's GIT as of 11:00pm.
Good news is it seems that you fixed my bug :-)
Bad news is i have a new regression : the character is no longer drawn on
screen. Only the weapons are... :-(
I will apply your patchset against 1.1.40 tomorrow, to try to determine whether
it's your new code or someone else's work recently fed into GIT.

Thanks a lot for your efforts!

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #9 from Sébastien Fiévet   2010-03-13 09:52:27 ---
I just applied incrementally your patchset against v1.1.40.
"Bad" patch is :
0006-WineD3D-Check-if-there-s-an-actual-conversion-done-b.patch.
Every patch from 0001 to 0005 are no-op for the crash. 0006 seems to fix it,
but introduces a new regression as described in my previous comment.
I did not apply patch 0007 afterward...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #10 from Stefan Dösinger   2010-03-14 04:36:53 ---
Can you attach a screenshot of the regression introduced by patch 6? (Before
and after screenshot)

It doesn't really make sense that patch 6 fixes the crashes, at least not if
the bug is alignment related...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #11 from Sébastien Fiévet   2010-03-14 13:14:41 ---
Created an attachment (id=26801)
 --> (http://bugs.winehq.org/attachment.cgi?id=26801)
pre-patch : scene OK (the character holds his gun in his hands)

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #12 from Sébastien Fiévet   2010-03-14 13:15:51 ---
Created an attachment (id=26802)
 --> (http://bugs.winehq.org/attachment.cgi?id=26802)
post-patch : scene KO (only the gun is displayed)

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #13 from Sébastien Fiévet   2010-03-14 13:17:56 ---
(In reply to comment #10)
> Can you attach a screenshot of the regression introduced by patch 6? (Before
> and after screenshot)
>
> It doesn't really make sense that patch 6 fixes the crashes, at least not if
> the bug is alignment related...

Here you are... Hope this will give you a clue.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #14 from Stefan Dösinger   2010-03-15 06:04:09 ---
Interesting. I can't reproduce that. What version of call of duty 4 is this(I
am running the Steam version, so it should be up to date). Also, what graphics
driver are you using?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #15 from Stefan Dösinger   2010-03-15 06:05:35 ---
Oh, some more things: Do you see any opengl errors in the output? Is this the
single or mullti player game?

I also tested the patches separately, and for me the alignment patch fixes the
game, not the conversion checking patch.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #16 from Sébastien Fiévet   2010-03-15 07:39:02 ---
This is CoD4 v1.7 (should be latest patch), without steam.
I have Nvidia binary drivers v195.30. I can downgrade to 190.53 if you think
it's worth it.
It was a dummy multiplayer game : i launched a server locally and joined the
game on my own to test your patchet. The game kept crashing until patch 6,
where both the crash and "my" hands disappeared... :-)

About the OpenGL errors, I'll check tonight and report.
Please tell me if you need something else.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #17 from Stefan Dösinger   2010-03-15 10:18:19 ---
I'm sorry, I can't reproduce either issue. Prior to patch 6 the game is stable,
and after patch 6 the hands render properly. Do you have any other hacks in
your wine tree? Do you have the current git code?

I am using the 195.36.03 driver(the beta version).

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #18 from Sébastien Fiévet   2010-03-15 11:45:01 ---
I don't have a single hack in my wine tree. I applied the whole patchset
against GIT before reporting... Then incrementally against v1.1.40.
I can try incrementally against GIT...

Out of topic, 195.36.0x has been disqualified by NVidia as potentially
dangerous for the hardware. It may cause the fan to stop, and the graphic board
to be overheated.

Anyway, i'll report GL errors if any.

Thanks again for your kind support.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #19 from Stefan Dösinger   2010-03-15 15:28:40 ---
I tried to downgrade to 190.53 now that gentoo has a patch that makes the
nvidia module compile on 2.6.33, but I still cannot reproduce this issue. What
graphics card do you have? Maybe one of the new geforce 8+ extensions hides the
bug. I have a geforce 9600(mobile in a laptop so I don't worry about the
nonexistant GPU fan)

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #20 from Stefan Dösinger   2010-03-15 16:28:07 ---
I did another test: I cannot crash the game even if I deliberately provide it
with unaligned pointers. (Align them to 16 byte first, then offset the pointer
by 1). So I can't reproduce the original bug at all. If I disable my GL address
alignment code the game runs just fine too.

However, with the screwed up alignment neither hand nor weapon render.

My game version is 1.7.563. This are my graphics settings:

Video Mode: 640x480, windowed(in config file)
Sync frame: No
Dual Video cards: no
Shadows yes
Spec map: yes
Depth of field: yes
Glow: Yes
Dynamic lights: normal
Soften Smoke edges: yes
Ragdoll: yes
Bullet impacts: yes
Model and water detail normal

Is any special map needed to provoke the crashes? or any special in-game
action?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #21 from Sébastien Fiévet   2010-03-16 16:41:29 ---
(In reply to comment #20)

My video card is a 9800GT "green edition".
PCI Device ID:0x0614
PCI Vendor ID:0x10de

Game version is 1.7.568, same as yours (i guess 1.7.56"3" was a typo).

To investigate the new rendering issue, i tested the game with the settings you
used, under wine-1.1.37 and 1.1.40 patched. I attached the log generated in
both cases. I hope you'll find something useful in it...

BTW I am curious to know if your settings gave your weird visual / low FPS, as
you should have run into 2 long standing bugs : bug 20307 and bug 16641...

I don't do anything special to make the game crash : just wander in the map...
It's neither map related nor action related.

I am going to recompile 1.1.40 without your patchset and run the game with your
settings to have a 3rd log... Stay tuned! ;-)

... and thank you so much for your help. I deeply appreciate.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #22 from Sébastien Fiévet   2010-03-16 16:43:29 ---
Created an attachment (id=26848)
 --> (http://bugs.winehq.org/attachment.cgi?id=26848)
log generated with wine-1.1.37

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #23 from Sébastien Fiévet   2010-03-16 16:44:09 ---
Created an attachment (id=26849)
 --> (http://bugs.winehq.org/attachment.cgi?id=26849)
log generated with wine-1.1.40 + your patchset

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #24 from Stefan Dösinger   2010-03-17 04:26:22 ---
I did run into bug 16641, but there's a workaround: edit swapchain.c and
device.c to force render_to_fbo on. I didn't run into bug 20307 - shadows work
just fine.

Current git should fix the crashes, I guess it doesn't work for you though.
What behavior do you get? Still crashes?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #25 from Sébastien Fiévet   2010-03-17 05:28:51 ---
(In reply to comment #24)
> I did run into bug 16641, but there's a workaround: edit swapchain.c and
> device.c to force render_to_fbo on. I didn't run into bug 20307 - shadows work
> just fine.

About bug 20307, i'd say it's unnoticeable when running in a 640x480 window...
I
experienced it myself yesterday. But you can't miss it in 1680x1050 fullscreen.
Toggling shadows on/off _really_ impacts the framerate. But this is off-topic
:-)

How about the log i attached? One exhibits a GL_error, the other doesn't.

I'll test git hopefully tonight. May be should i regenerate a +d3d,+tid log?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #26 from Stefan Dösinger   2010-03-17 06:03:56 ---
A log comparing 1.1.40 to 1.1.40 with my patches would be better than the
1.1.37 to 1.1.40+patches comparison. Do the GL errors occur repeatadely while
playing? Or just during loading?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #27 from Sébastien Fiévet   2010-03-17 18:23:44 ---
Created an attachment (id=26863)
 --> (http://bugs.winehq.org/attachment.cgi?id=26863)
log generated with wine-1.1.40 WITHOUT your patchset

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #28 from Sébastien Fiévet   2010-03-17 18:25:48 ---
(In reply to comment #26)

I generated the log with 1.1.40 prepatch. Theres's no GL errors, but it crashes
the game. With your patchset, the GL errors occurs repeatedly, and _only_ while
playing, not during loading... And the game doesn't crash!

The log files of 1.1.37 and 1.1.40 look pretty similar to me. Except for the
crash logged in for 1.1.40... I'll test GIT version tomorrow.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #29 from Sébastien Fiévet   2010-03-18 13:52:11 ---
I just tested GIT as of today, 7:50pm CET.
It crashes just as 1.1.40 does. It seems to me that not all your patchset has
been commited. 
What should i do to give you any clue?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #30 from Stefan Dösinger   2010-03-18 14:30:08 ---
I didn't submit the conversion check patch that fixes the bug for you yet
because I want to find out what is going on with cod4 on your machine.

I'll run some tests on my other machines and see if I can spot anything. If
not, I'll send the patch(it really shouldn't break anything) and see if we get
some lucky clues in the future.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #31 from Sébastien Fiévet   2010-03-21 12:56:36 ---
Just to say that the game still crashes with v1.1.41...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #32 from Stefan Dösinger   2010-03-21 16:24:27 ---
Hi,
I can't reproduce the crashes nor the hand drawing bug on my geforce 7 card.

Btw, my game version is indeed 1.7.568, I misread the 8 as a 3 because there
are some unlucky antialiasing / filtering effects in that very row of the
letter texture at 640x480...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #33 from Sébastien Fiévet   2010-03-22 04:09:39 ---
(In reply to comment #32)

Would a +d3d,+tid log finally be helpful? And if it is as huge as the first
time, which part would be interesting for you?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #34 from Stefan Dösinger   2010-03-22 06:49:27 ---
Ya, please create such a log, take the last 50 MB of it, compress them and
attach them here. If the last 50 MB don't compress well enough(which would
surprise me), attach as much data from the end of the log as possible.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #35 from Sébastien Fiévet   2010-03-23 04:36:23 ---
Created an attachment (id=26992)
 --> (http://bugs.winehq.org/attachment.cgi?id=26992)
backtrace of CoD4 with v1.1.41 +d3d,+tid

Here you are... I splitted the whole log file (2.3G) into slices of 50M each
and stored it. If you need some more, tell me.
I looked at the log and feel pessimistic... I don't see much errors/fixme
inside.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #36 from Sébastien Fiévet   2010-03-29 08:26:49 ---
Hi Stephan,

did you find some time to take a look at the +d3d,+tid log file i generated?

Thanks, Seb.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #37 from Stefan Dösinger   2010-03-31 10:16:02 ---
Hmm, I thought I replied to this bugreport already. Maybe I did so in the train
and the connection collapsed.

Can you add +d3d_draw to the log? The crash seems to occur during state
application or drawing. Adding +d3d_draw should tell those apart.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #38 from Sébastien Fiévet   2010-04-02 03:31:10 ---
Created an attachment (id=27155)
 --> (http://bugs.winehq.org/attachment.cgi?id=27155)
backtrace of CoD4 with v1.1.41 +d3d,+tid,+d3d_draw

Here you are!

FWIW, i had to generate the log twice, because the first time wine filled up
the remaining 4Gb of free space on my disk. The gameplay was painfully slow
(2-3 FPS), and it took ages to drag the game to the crash point.

I cleaned up my disk to gain free space and relaunched the game. It ran
surprisingly faster (8 FPS!), crashed faster, and the log file was 1.7Gb, which
is about half the size of the first run...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #39 from Stefan Dösinger   2010-04-02 04:24:17 ---
It is crashing inside the draw call. And the bad address was provided from a
vertex buffer:

0009:trace:d3d:buffer_Map Returning memory at 0x52b09000 (base 0x52b09000,
offset 0)

It starts to make sense that the patch that avoids the non-vbo fallback fixes
the crash. If there's a bad vbo the driver is more likely to just not draw
stuff instead of crashing. I still have to figure out why the buffer's memory
isn't there.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26992|0                           |1
        is obsolete|                            |
  Attachment #27155|0                           |1
        is obsolete|                            |

--- Comment #40 from Stefan Dösinger   2010-04-02 04:32:04 ---
Created an attachment (id=27157)
 --> (http://bugs.winehq.org/attachment.cgi?id=27157)
Print more debug info in buffer::preload

Hi,
Can you redo the d3d,tid,d3d_draw log with this patch? It would print more
information about the vertex buffer's state in buffer_preload, which is
helpfully called right before the crash.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #41 from Sébastien Fiévet   2010-04-02 17:36:42 ---
Created an attachment (id=27166)
 --> (http://bugs.winehq.org/attachment.cgi?id=27166)
backtrace of CoD4 with v1.1.41 +d3d,+tid,+d3d_draw AND "debug info" patch

Here it is!

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #42 from Stefan Dösinger   2010-04-03 03:24:21 ---
> 0009:trace:d3d:buffer_PreLoad Buffer flags 0, vbo 0, heapMem (nil)

There's no VBO and no memory allocated. That's not good.

Unfortunately, the buffer is already in this state when your log starts. And
there are multiple draw calls with the broken buffer that succeed. Fairly
strange.

Can you change the debug line my log added to additionally print
This->resource.allocatedMemory? I expect it to be non-null. If that is the case
it's possible that heapMemory is freed at some point, allocatedMemory not
unset, and the originally allocated memory stays around in some orphaned state.
When the kernel decides to unmap it from the app's address space the game
crashes.

I'll see if I can reproduce the vbo = 0 heapmem = NULL behavior here. Should be
more reproducible than the crashes themselves.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #43 from Sébastien Fiévet   2010-04-03 04:53:32 ---
Created an attachment (id=27176)
 --> (http://bugs.winehq.org/attachment.cgi?id=27176)
backtrace of CoD4 with v1.1.41 +d3d,+tid,+d3d_draw AND MODIFIED "debug info"
patch

It sounds like you guessed right! :-D

I quickly browsed the log, and i saw lines where both heapMemory and
allocatedMemory are (nil), and some where only heapMemory is.

You are on the right track.
Thank you so much for your patience and dedication.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #44 from Stefan Dösinger   2010-04-04 04:53:48 ---
I checked the code, there should be no place where heapMemory is set to NULL,
but allocatedMemory isn't zeroed either. The only exception is the VBO path of
_Map and _Unlock, where allocatedMemory is set without assigning HeapMemory.

Can you find out where the "bad" pointer in AllocatedMemory is coming from? The
only explanation I can find is that the app maps the buffer, then for some
reason it is unloaded(e.g. device::reset is called). Thus the VBO disappears
but the old allocatedMemory pointer still remains.

To do that just add a ERR printout to every place where allocatedMemory is
assigned and then after a crash search for the bad address that causes the
crash in that log. Note that there's also one assignment in resource.c

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #45 from Sébastien Fiévet   2010-04-05 10:16:44 ---
(In reply to comment #44)

'grep "This->resource.allocatedMemory =" dlls/wined3d/*.c' gave me occurrences
in :
   - buffer.c
   - resource.c
   - surface.c
   - surface_gdi.c
   - volume.c

Ignoring NULL assignations, there were 13 remaining occurrences, which i tagged
with an ERR message. Among all 13, there's only one that appears in the log,
and it's the one from "buffer_Map" (buffer.c, line 1182) :
This->resource.allocatedMemory =
GL_EXTCALL(glMapBufferRange(This->buffer_type_hint, 0,                         
This->resource.size, mapflags));
> From this point on, i don't know how to continue... I'am attaching the last

bits of the log, where the last occurrence of my ERR message arises before the
crash, hoping you'll see something.

Search for the last "err:d3d:buffer_Map -I2-" string, and you'll be there.

BTW, in (ressource.c, line 102-103) shouldn't resource.allocatedMemory and
resource.heapMemory be reset to NULL rather than '0'?

'Hope i did what you expected from me... If not please tell me and i'll redo.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #46 from Sébastien Fiévet   2010-04-05 10:20:53 ---
Created an attachment (id=27221)
 --> (http://bugs.winehq.org/attachment.cgi?id=27221)
backtrace of CoD4 with v1.1.41 +d3d,+tid,+d3d_draw MODIFIED "debug info" patch
and ERR printouts

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #47 from Stefan Dösinger   2010-04-05 14:07:22 ---
H,
You're on the right track, just a few changes:

* Don't use +d3d,d3d_draw this time, then you should be able to attach the
entire log. You can use +tid, it doesn't make the log much larger as it doesn't
add any messages on its own, just the thread ID to each message

* You can ignore surface.c, surface_gdi.c and volume.c, the surface and volume
code doesn't (yet) intersect with the buffer code. It may do that later for
d3d10 purposes.

* Print the buffer and the address in the ERRs, for example
ERR("%p: setting allocatedMemory to %p\n", This,
This->resource.allocatedMemory);
Also print the NULL assignments for completeness.

Note that you don't have to be afraid to pass a NULL pointer to a %p format, it
will just print "(nil)", e.g. "0xdeadbeef: setting allocatedMemory to (nil)".

Wrt setting heapMemory and allocatedMemory to NULL instead of 0: you are
correct, but it is a minor point. NULL is defined as "(void *) 0". It doesn't
even cause a integer-to-pointer conversion warning because gcc apparently
special cases assining 0 to a pointer as ok.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #48 from Sébastien Fiévet   2010-04-05 17:30:51 ---
Created an attachment (id=27232)
 --> (http://bugs.winehq.org/attachment.cgi?id=27232)
backtrace of CoD4 with v1.1.41 +tid AND detailed ERR printouts WITHOUT "debug
info" patch

This time i tracked ALL assignments of allocatedMemory in buffer.c and
resource.c. As for my first attempt, i indexed ERR messages after their order
of appearance from I1 to I7. I1 to I6 belonging to buffer.c and I7 to
resource.c

As per your example, I used :
ERR("-I[1-7]- buffer : %p, allocatedMemory : %p, heapMemory : %p\n",
    This, This->resource.allocatedMemory, This->resource.heapMemory);

'Hope we're getting close to something!

Many, many (many) thanks again.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #49 from Sébastien Fiévet   2010-04-06 04:20:21 ---
I just took a close look at the log I generated yesterday, and i found
something curious : The faulting address seems to be bound to 2 concurrent
buffers.
They are created sequentially, but the first one is not unmapped before the
second one is created :

[snip]
0009:err:d3d:buffer_Map -I3- buffer : 0x1c2a3ae0, allocatedMemory : 0x51259000,
heapMemory : (nil)

0009:fixme:d3d:buffer_Map >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from
glMapBufferRange @ buffer.c / 1188
0009:err:d3d:buffer_Map -I3- buffer : 0x1c25f498, allocatedMemory : 0x53342000,
heapMemory : (nil)
0009:err:d3d:buffer_Unmap -I6- buffer : 0x1c25f498, allocatedMemory : (nil),
heapMemory : (nil)
0009:fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION
(0x502) from glDrawElements @ drawprim.c / 47
0009:fixme:d3d:buffer_PreLoad Too many full buffer conversions, stopping
converting

0009:err:d3d:buffer_Map -I3- buffer : 0x17ca8338, allocatedMemory : 0x51259000,
heapMemory : (nil)
[snip]

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #50 from Stefan Dösinger   2010-04-06 04:39:20 ---
Hmm, apparently wined3d is trying to create a GL buffer object for the d3d
vertex buffer while the buffer is mapped. That won't work well.

Can you attach the diff of your changes, just for completion? And I am afraid I
need the full +d3d,+tid log of a crash run, WITH your allocatedMemory debug
lines in place. Try to compress it with lrzip. If it attaches to bugzilla file,
otherwise try to mail it to [e-mail].

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #51 from Sébastien Fiévet   2010-04-06 16:46:39 ---
Created an attachment (id=27248)
 --> (http://bugs.winehq.org/attachment.cgi?id=27248)
print debug info for allocatedMemory assignements

Here is the diff of my changes.
I compressed the +d3d,+tid log file with bzip2 and uploaded it at :
http://sebastien.fievet.free.fr

You can safely fetch it : this page is provided to me by my ISP.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #52 from Stefan Dösinger   2010-04-09 13:22:29 ---
Created an attachment (id=27301)
 --> (http://bugs.winehq.org/attachment.cgi?id=27301)
Check for mapped buffers in preload

It seems that the game draws while the buffer that it uses for drawing is
mapped. This isn't legal in GL, and I am pretty sure shouldn't be legal in d3d.
The game may get away with it by luck however.

Can you try this patch? If checks if the buffer is mapped when PreLoad is
called, and if it is, prints an error message and causes the app to exit(so
other FIXMEs don't spam too much). It should confirm or deny my theory.

I think this is what happens:

1) The app creates a buffer
2) It maps the buffer
3) It draws with the buffer
In this step the original map address is already freed and invalidated, but
this doesn't have to cause a crash. We're (correctly) setting up GL to draw
from the buffer.
4) It unmaps the buffer
This step generates a GL error. However, the checkGLcall call for the unmap
buffer call is missing, so you don't see it yet. (We should add a checkGLcall
line there)
5) It locks the buffer again
At this point, the GL buffer is mapped. A checkGLcall line is executed and
retrieves the error generated in step 4, which wasn't seen yet by (bad) luck.
This explains why glMapBufferRange seems to generate an error but still returns
a valid address.
6) The app draws from the buffer. This generates another GL error because the
buffer is mapped
7) Unmap
8) 5-7 repeat a few times.
9) At some point PreLoad (incorrectly) drops the GL buffer because it thinks it
will work more efficiently without it. No new heapMemory is allocated because
resource.allocatedMemory is already set. The mapped GL memory is lost.
10) At some point the kernel cleans up the memory and the app crashes.

Now, with the patch that fixes the incorrect VBO drops, the VBO is not
released, and the memory never becomes invalid. However, the app keeps drawing
while the buffer is mapped, which is correctly rejected by GL.

I do not see the draw-with-mapped-buffer behavior myself. I have two theories:
*) Do you have a cracked game? Maybe the crack is bad.
*) There's an unexpected exception somewhere between the Map and the draw, and
the app catches this exception. So it doesn't crash outright, but doesn't
properly work either.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #53 from Stefan Dösinger   2010-04-09 13:26:01 ---
> *) There's an unexpected exception somewhere between the Map and the draw, and
> the app catches this exception. So it doesn't crash outright, but doesn't
> properly work either.

I pressed the submit button a little bit early (as usual). Can you add +seh to
the big log you put on your webspace? This should show if there are any
exceptions between the map and draw calls.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Wylda  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #54 from Wylda   2010-04-11 04:48:05 ---

For me it does not crash, but instead of that following commit causes glitches
and artifacts in the picture.

commit 224043d6cf8b56e9ff2537358646700211d54d1f
wined3d: Implement dynamic buffers with GL_ARB_map_buffer_range.

In the evening, i'll try your patch Stefan, if that helps to get rid of those
artifacts.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #55 from Stefan Dösinger   2010-04-11 07:30:47 ---
Which kinds of artifacts? Can you attach a screenshot?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #56 from Wylda   2010-04-11 12:49:56 ---
Created an attachment (id=27333)
 --> (http://bugs.winehq.org/attachment.cgi?id=27333)
wine-1.1.38 vs reverted Implement dynamic buffers in 1.1.38

(In reply to comment #55)
> Which kinds of artifacts? Can you attach a screenshot?

Side note:
Do not care about "Parasite snowing". It's not recent fault. If i remember
correctly, i have the "snowing" since i began to use wine (different nvidia
drivers, kernels, wines, etc..). WinXP doesn't have this snowing. CoD4 v1.7

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #57 from Wylda   2010-04-11 13:00:32 ---

Forgot to mention - of course happens even on wine-1.1.42-182-g8f77dd8 and
patch http://bugs2.winehq.org/attachment.cgi?id=27301 doesn't help.

nVidia v195.36.15

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #58 from Stefan Dösinger   2010-04-11 16:07:43 ---
Ah, I know those issues. I am seeing them only when I hack out the glFlush
calls that are supposed to synchronize the draw order across threads. My
suspicion was that one thread sets the texture address mode of some (dynamic)
textures and that interferes with the commands scheduled in the other thread. I
didn't verify that yet, but I'll take a look at how the dynamic buffer stuff
affects this.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Eric Lanz  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #59 from Sébastien Fiévet   2010-04-13 12:38:23 ---
Back on air!

to reply to your question in comment #52 : i have an original game, but i use a
"no_cd" crack because the copy protection used to crashed wine by the time i
installed the game.

I ran the game with your "Check for mapped buffers in preload" patch and have
been kicked out as soon as i entered the map, the last log message being :
"err:d3d:buffer_PreLoad PreLoading mapped buffer!!!"

Shall i generate the "+d3d,+tid,+seh" backtrace with the above patch in place
or without it?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #60 from Stefan Dösinger   2010-04-13 13:20:35 ---
Generate the log with the patch in place. That way it will be much shorter.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #61 from Sébastien Fiévet   2010-04-13 16:23:06 ---
(In reply to comment #60)
> Generate the log with the patch in place. That way it will be much shorter.

Here you are. I upload it to my webspace as last time.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #62 from Rico   2010-04-15 10:57:21 ---
Could you please try the hack from bug 18799
(http://bugs.winehq.org/attachment.cgi?id=27310)?

It seems that this fixes the screen corruptions.

@Sébastien
Does the hack fix the crash for you?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #63 from Stefan Dösinger   2010-04-15 11:54:49 ---
The patch should avoid crashes and GL corruptions that occur due to
draw-while-mapped situations. It's not a correct fix however.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #64 from Rico   2010-04-15 12:40:32 ---
Created an attachment (id=27372)
 --> (http://bugs.winehq.org/attachment.cgi?id=27372)
workaround, which disables the usage of GL_MAP_INVALIDATE_BUFFER_BIT

This is probably a better workaround.

Some patch from today broke cod4 horribly, so please try with the git from
yesterday.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #65 from Wylda   2010-04-15 14:35:15 ---
(In reply to comment #64)
> Some patch from today broke cod4 horribly, so please try with the git from
> yesterday.

Filled in bug 22366.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #66 from Wylda   2010-04-15 15:40:35 ---
(In reply to comment #64)
> Created an attachment (id=27372)

--> (http://bugs.winehq.org/attachment.cgi?id=27372) [details]
> workaround, which disables the usage of GL_MAP_INVALIDATE_BUFFER_BIT
>
> This is probably a better workaround.

Yes, this fixes the graphical issue for me.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #67 from Sébastien Fiévet   2010-04-16 16:20:50 ---
(In reply to comment #62)
> @Sébastien
> Does the hack fix the crash for you?

FWIW, i applied Attachment 27372 first with Attachment 27301 in place to see
whether the crash was still triggered or not, and it was. Hence, it is more a
workaround than a fix to the root cause of the problem. :-(

OTOH, without Attachment 27301 in place, the crash is not triggered anymore (or
a least it was not during my relatively short test session), which makes me
temporarily happy! :-)

@Stephan : have you had time to take a look at the +seh backtrace i generated?
Does it contains relevant information?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #68 from Wylda   2010-04-17 02:11:25 ---
(In reply to comment #67)
> OTOH, without Attachment 27301 [details] in place, the crash is not triggered

I think you just had luck... Because if you hit the bug with Attachment 27301,
then wine would exit back to command prompt. That's what exit is meant for,
isn't?

During the retest of bug 22366, CoD froze and i had to kill it. So now i know,
that i'm in the right club here :) Recapitulation: wine-1.1.43 freezes/crashes
and has graphical issues. Fingers crossed for Stefan & bug hunting :)

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #69 from Stefan Dösinger   2010-04-18 10:13:45 ---
There is no exception between the map that the draw. That leaves two
possibilities:

1) your game expects an error back at some point, most likely from
drawPrimitive. This is unlikely because drawPrimitive doesn't do much checks.
If something is wrong it either draws junk or crashes.

2) Your crack breaks the game, and it gets away with it on Windows by luck.
Wylda is also using the non-Steam version of the game and it works. I'm using
the Steam version and it works. Can you try the game without a crack and see if
it fixes the crash?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #70 from Stefan Dösinger   2010-04-18 10:23:35 ---
Hmm, I think I didn't read post #68 carefully enough. Wylda, Does that mean
it's crashing for both of you? Or was the crash a one-time occurance?

Attachment 27301 is a good test if the game draws from locked buffers. If it
ever does, it exits, if it crashes but doesn't print the ERR message added by
the patch the crash is caused by something different.
> From Sébastien's logs it seems that if the game draws from locked buffers it

does that *all* the time, it's just that you can be lucky for quite a while and
the game doesn't crash because of this bug.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #71 from Sébastien Fiévet   2010-04-18 13:06:53 ---
(In reply to comment #70)

I removed my .wine directory, removed wine, installed v1.1.43 from scratch, and
re-installed the game in my new-born .wine prefix.

With game v1.6 from the DVD, the copy protection crashes, but with patch v1.7
applied, the game doesn't even check for the disc in the drive, so i can play
from a regular CoD4 installation! :-)

1- vanilla v1.1.43 crashes.
2- v1.1.43 + Attachment 27301 crashes immediately.
3- v1.1.43 + Attachment 27372 seems to work (no crash within 15 minutes). I'll
thoroughly test tomorrow night as i have a LAN over VPN session...

(In reply to comment #69)
Stephan, please don't be offended, but from my work experience, the bug is very
(very) often where it cannot be... After Murphy's law point #1 is definitely a
good candidate! ;-)

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #72 from Stefan Dösinger   2010-04-18 13:42:31 ---
> 2- v1.1.43 + Attachment 27301 [details] crashes immediately.
> 3- v1.1.43 + Attachment 27372 [details] seems to work (no crash within 15 minutes). I'll

What happens when you apply both of them?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #73 from Sébastien Fiévet   2010-04-18 16:07:47 ---
(In reply to comment #72)
> What happens when you apply both of them?

I already tried with v1.1.41 (comment #67)... Tried again with 1.1.43, not to
let any possibility unexplored.
4- v1.1.43 + Attachment 27301 + Attachment 27372 crashes immediately.

Thanks again for your help Stephan... Please let me know if i can be oh any
help.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #74 from Stefan Dösinger   2010-04-19 09:34:49 ---
I wrote a test that tests drawing from locked buffers, and I get an error back
on Windows 7. Windows Vista and Win2k with the reference rasterizer accept the
draw. Do you have a Windows 7 installation with a hardware GPU? If yes, can you
try your game on it and see if it works?

I'll write a wined3d patch that returns an error to the game instead of just
calling exit. We'll see what happens...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #75 from Sébastien Fiévet   2010-04-20 02:58:28 ---
(In reply to comment #74)
> I wrote a test that tests drawing from locked buffers, and I get an error back
> on Windows 7. Windows Vista and Win2k with the reference rasterizer accept the
> draw. Do you have a Windows 7 installation with a hardware GPU? If yes, can you
> try your game on it and see if it works?

I can manage to have my copy of the game installed on a machine running a
regular copy of windows7. I'll do before the weekend.
> I'll write a wined3d patch that returns an error to the game instead of just
> calling exit. We'll see what happens...

I played about 2 hours yesterday night with v1.1.43 + Attachment 27372 and
didn't experience a single crash...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #76 from Stefan Dösinger   2010-04-20 12:07:19 ---
> I played about 2 hours yesterday night with v1.1.43 + Attachment 27372 [details] and
> didn't experience a single crash...

I don't understand how this would happen. We still drop the VBO, so the memory
that once pointed into the mapped buffer is likely to disappear at some point.
It's possible that removing this flag stops the driver from reallocating
*other* VBOs, so it doesn't mix around memory allocations that much.

The basic problem(draw-while-locked) still remains.

It's not too hard to work around this specific problem your game hits. Just
catch the behavior, don't create a VBO for this specific buffer, and we have
well-defined and valid GL calls, and no dangling pointers. It just seems wrong
to me, and I still don't think that there isn't a way to stop the game from
doing these broken calls.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #77 from Sébastien Fiévet   2010-04-20 15:58:55 ---
(In reply to comment #76)

I agree on the fact that a real fix is better than a workaround.
I just wanted to report on the robustness of *this* workaround as i committed
myself to do so! :-)

I should have the result of the test on Win7 hopefully next Thursday.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #78 from Sébastien Fiévet   2010-04-22 06:39:12 ---
(In reply to comment #77)
> I should have the result of the test on Win7 hopefully next Thursday.

I asked a friend of mine to install my (original) game under his (original)
win7, and to test and report any crash he may face during our weekly LAN over
VPN session. The game didn't crash once over the 2 hours game session.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #79 from Stefan Dösinger   2010-04-22 13:36:42 ---
I guess I'll write a patch that returns an error to the game if it draws from a
locked buffer, then we can see how it reacts to that. Do you know if the hands
on the weapon showed up properly?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #80 from Sébastien Fiévet   2010-04-22 15:06:06 ---
(In reply to comment #79)
Yes : The game worked flawlessly, without any graphical corruption.
Don't give up Stephan : This (long) bug hunting is eventually gonna end up
somewhere!

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #81 from Stefan Dösinger   2010-05-05 13:04:40 ---
Wrt the INVALIDATE_BUFFER issue, this seems to be a threading problem. If I
disable VBOs and fill the buffer with random garbage(or zeroes, or ones) I get
no corruption. I suspect when one thread invalidates the buffer and writes new
data into it, the update isn't properly propagated to the other thread(GL
context) and it draws from the old buffer content.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #82 from Sébastien Fiévet   2010-05-06 03:22:57 ---
(In reply to comment #81)
would you like me to test something then?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #83 from Wylda   2010-05-09 16:38:19 ---

I still have a problem in wine-1.1.44-19-gd2a0188 as shown
http://bugs2.winehq.org/attachment.cgi?id=27333

And also CoD4 MW still freezes. Do you want me guys to leave this bug report
and open a new one at least for graphical corruption?

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

--- Comment #84 from Sébastien Fiévet   2010-05-30 05:22:38 ---
Since you are in the process of releasing, i think i should give a status on
that bug. Disabling usage of GL_ARB_map_buffer_range suppressed the crash, as
of 1.2-RC1.

Thanks again for your kind support...

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Wylda  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #85 from Wylda   2010-06-19 15:08:55 ---

Problem http://bugs2.winehq.org/attachment.cgi?id=27333 is fixed in
wine-1.2-rc4

Particular commit (wine-1.1.44-63-g481aca4):
http://source.winehq.org/git/wine.git/?a=commit;h=481aca47ad649297e5435d0f4c...

Marking fixed, because OR is also happy in comment #84.

[Bug 21962] Call of Duty 4 crashes

http://bugs.winehq.org/show_bug.cgi?id=21962

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #86 from Alexandre Julliard   2010-06-25 12:41:30 ---
Closing bugs fixed in 1.2-rc5.