Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Age of Conan crashes on start #130

Closed
Altosk opened this issue Aug 22, 2015 · 34 comments
Closed

Age of Conan crashes on start #130

Altosk opened this issue Aug 22, 2015 · 34 comments

Comments

@Altosk
Copy link

Altosk commented Aug 22, 2015

On a nine apitrace it crashes on IDirect3DTexture9::UnlockRect and hard locks my computer but using D3D_ALWAYS_SOFTWARE=1 allowed me to get the trace. Replaying the trace file in qapitrace complains about an unhandled exception.

Playing a trace file of wined3d on nine crashes at DrawIndexedPrimitive.

amd r2 290x is my video card

@sarnex
Copy link
Member

sarnex commented Aug 22, 2015

Come to #d3d9 on irc.freenode.net and ping me, we have an apitrace server. Also, can you post the log with NINE_DEBUG=all, thanks.

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

heres NINE_DEBUG=all log
https://www.sendspace.com/file/qe1k88

@axeldavy
Copy link

I think the application is writing outside the buffer.
We see in the log it uses ATI2 format (likely not supported on llvmpipe, thus why you don't hit the bug).

ATI2 is a special format that relies on a hack to work:
the info returned to the app is wrong, but the app knows that it is wrong for this format,
and deduces the correct info from the wrong info.
We do specially the 'wrong behaviour' for this format, but it looks like
we do only when the buffer is in cpu memory.
All games tested so far using this format were filling the data in cpu memory, and then would copy to gpu memory.
Here the game maps the gpu memory and writes to it.

Can you try the following thing (hoping that will be sufficient, because else some tricks may be needed):

at surface9.c, line 408
replace the line
pLockedRect->Pitch = This->transfer->stride;
with
if (is_ATI1_ATI2(This->base.info.format))
pLockedRect->Pitch = This->desc.Height;
else
pLockedRect->Pitch = This->transfer->stride;

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

tested and crashed but wine d3d trace played till the end
new log : https://www.sendspace.com/file/l9lihc

@axeldavy
Copy link

Is it the log for the wined3d trace ?

Wine doesn't advertise ATI2 on radeonsi, the change I asked you to do shouldn't change anything to the fact it runs or not.

Is it crashing at same location ?
If yes, I guess a bigger fix is needed, I will tell here when I have written it.

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

no the log is from nine.
wined3d replay crashed a drawindexedprim on nine now it doesnt which is weird given what you said

@axeldavy
Copy link

ok, I wrote something.
I test it doesn't regress anything else, then I'd ask you to test

@axeldavy
Copy link

Ok, can you test current git and report ?

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

ok compiling now

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

tested with git still crashes and i tried with both the patch on git and what you suggested

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

actually hang on i mess up compiling

@Altosk
Copy link
Author

Altosk commented Aug 22, 2015

still crashes. my other games work fine now.

@axeldavy
Copy link

There is likely some other factors intervening.

are you compiling with gcc 5.0 or gcc 5.1 ?

@Altosk
Copy link
Author

Altosk commented Aug 23, 2015

gcc 4.9.3

@axeldavy
Copy link

Is it crashing at the same location than before ?

@Altosk
Copy link
Author

Altosk commented Aug 23, 2015

nine:unknown:QueryInterface: This=0x7cbb6028 riid=0x33e2f8 ppvObject=0x33e2f4
nine:basetexture9:Dump:
NineBaseTexture9(0x7cbb6028->NULL/0x7cbb6108): Pool=DEFAULT Type=TEXTURE Usage=
Format=D3DFMT_A8R8G8B8 Dims=32x16x1/1 LastLevel=5 Lod=0(4294967295)
nine:device9:CreateTexture: This=0x7c54c490 Width=32 Height=16 Levels=0 Usage= Format=D3DFMT_A8R8G8B8 Pool=DEFAULT ppOut=0x33e66c pSharedHandle=(nil)
nine:texture9:ctor: (0x7cbb7628) Width=32 Height=16 Levels=0 Usage= Format=D3DFMT_A8R8G8B8 Pool=DEFAULT pSharedHandle=(nil)
nine:basetexture9:ctor: This=0x7cbb7628, pParams=0x33e504 initResource=(nil) Type=3 format=21 Pool=0 Usage=0
nine:resource9:ctor: This=0x7cbb7628 pParams=0x33e504 initResource=(nil) Allocate=1 Type=3 Pool=0 Usage=0
nine:resource9:ctor: (0x7cbb7628) Creating pipe_resource.
these are the last entries in my log.

@Altosk
Copy link
Author

Altosk commented Aug 25, 2015

to answer your question, yes it is still crashing in the same timeframe

@Altosk
Copy link
Author

Altosk commented Aug 25, 2015

dmesg complains about this : [ 226.084129] radeon 0000:01:00.0: va above limit (0x002032E6 > 0x00200000)
if thats is any help

@axeldavy
Copy link

I need to know whether the ATI1/ATI2 patch solves something or not.

Can you confirm the log looks different for you with the patch and without ?

@Altosk
Copy link
Author

Altosk commented Aug 30, 2015

okay ATI1/2 patch gets me farther when i compare the logs that I posted but it looks like it crashes at nine:resource9:ctor: (0x7cbb7d48) Creating pipe_resource now

@Altosk
Copy link
Author

Altosk commented Sep 6, 2015

replaying the trace on wined3d gives me this:
err:d3d:resource_init Failed to allocate system memory.
571 @0 IDirect3DDevice9::CreateTexture(this = 0x7c982c28, Width = 4096, Height = 4096, Levels = 0, Usage = 0x0, Format = D3DFMT_A8R8G8B8, Pool = D3DPOOL_DEFAULT, ppTexture = &0x7caeaf28, pSharedHandle = NULL) = D3D_OK
571: warning: failed with 0x8007000e (E_OUTOFMEMORY): Out of memory.

@Altosk
Copy link
Author

Altosk commented Oct 2, 2015

axel those patches do not help at all I just reverted and did a apitace after the revert and comparing it to one before revert shows it crashing at the same point as with the patches.

@Altosk
Copy link
Author

Altosk commented Oct 7, 2015

heres an apitrace https://www.sendspace.com/file/bjy5k9

@axeldavy
Copy link

axeldavy commented Oct 8, 2015

same thing apitrace really short and doesn't show the bug. Did you cut the trace or ?

@Altosk
Copy link
Author

Altosk commented Oct 8, 2015

i didnt cut the trace thats as far as i get with both apitraces i posted

@Altosk Altosk mentioned this issue Oct 23, 2015
@Altosk
Copy link
Author

Altosk commented Oct 26, 2015

latest git broke the patch that fixed the kernel crashing

@axeldavy
Copy link

what was the last working git for this game ?

@Altosk
Copy link
Author

Altosk commented Oct 26, 2015

I think theres a bug between the patch and thread_submit=true i removed it from the command line and the game crashes at the new point that i pointed at in the pull request.

@siro20
Copy link

siro20 commented Nov 14, 2015

For ageofConan the first patch is required (ATI1/ATI2 stride width) and there's a problem in nine resource management:
err = util_hash_table_set(This->pdata, refguid, header);
is wrong as the pointer refguid is stored in the list. The pointer is under application control and we don't know what happens to memory after leaving this function.
NineResource9_GetPrivateData isn't able to find the entry as the data where refguid is pointing to has changed.
The correct implementation would be to create a copy of GUID and store it in the header.
util_hash_table_set has to point to the GUID in the header, as it is under our control and the contents won't change.

siro20 added a commit to siro20/Mesa-3D that referenced this issue Nov 15, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue iXit#130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
@Altosk
Copy link
Author

Altosk commented Nov 15, 2015

with siro patch it start to a black screen with no movie or anything

siro20 added a commit to siro20/Mesa-3D that referenced this issue Nov 15, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue iXit#130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
@siro20
Copy link

siro20 commented Nov 15, 2015

The game plays when minimized and idle when in fullscreen, it looks like this is because of broken window handling.

axeldavy pushed a commit that referenced this issue Nov 21, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
axeldavy pushed a commit that referenced this issue Nov 27, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
@siro20
Copy link

siro20 commented Dec 6, 2015

The ticket should be closed as the bug is fixed.

@axeldavy axeldavy closed this as completed Dec 6, 2015
@Altosk
Copy link
Author

Altosk commented Dec 12, 2015

siro should i open another ticket about rendering when miminized and not when the window is in focus?

@siro20
Copy link

siro20 commented Dec 12, 2015

Yes please

axeldavy pushed a commit that referenced this issue Dec 12, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
axeldavy pushed a commit that referenced this issue Dec 27, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
axeldavy pushed a commit that referenced this issue Dec 29, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
axeldavy pushed a commit that referenced this issue Dec 30, 2015
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130.

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
axeldavy pushed a commit that referenced this issue Jan 1, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 2, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 2, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 8, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 9, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 26, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 28, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 29, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Jan 30, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
axeldavy pushed a commit that referenced this issue Feb 4, 2016
Store a copy of GUID in the header that is under our control and use it
as key for the hashtable instead of using the application provided pointer.
The application might change the memory after leaving the function.

Fixes a crash for issue #130

Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants