Re: EverQuest2.exe and context.c
Dan Kegel wrote: > Chris Ahrendt wrote: >> Again on the goto's I was following what the site >> suggested was a good task to start with > > Where does it say that? I looked, but I couldn't find it. > Please let me know so I can go make sure it's accurate. > > Wine code is a bit like kernel code, it has slightly different > conventions than most people are used to. > > Chris, you should focus on one thing at a time, and > code cleanup probably shouldn't be something you > focus on until you are more in tune with Wine. > > - Dan > > p.s. > Also, everybody, please trim your quotes... > > Thanks for the pointer Dan... here is the section I am talking about: Perform a focused code review Here are a few starting points: * Arrays of fixed sized like 'foo[100]'. 100, where does that come from? * Arrays of size 255, 256, 512, 1024. These are most likely variables destined to contain a path. But then they should be using one of the standard macros like MAX_PATH, MAX_PATHNAME_LEN or some such. Which one? * Calls to sprintf with an incorrect buffer size * Inefficient uses of strcat (not really a bug and not really vital) Required skills: * C programming A Typical code review I do when I go to clients includes the above but also includes such things as goto's and incorrect variable declarations.. Uninitialized variables... use of NULL instead of memset to set variables, etc... If there is a specific code convention that wine uses you might want to document or put a link here so there is no confusion. Only reason I started there was due to the simplicity implied =) chris
re: EverQuest2.exe and context.c
Chris Ahrendt wrote: > Again on the goto's I was following what the site > suggested was a good task to start with Where does it say that? I looked, but I couldn't find it. Please let me know so I can go make sure it's accurate. Wine code is a bit like kernel code, it has slightly different conventions than most people are used to. Chris, you should focus on one thing at a time, and code cleanup probably shouldn't be something you focus on until you are more in tune with Wine. - Dan p.s. Also, everybody, please trim your quotes...
Re: EverQuest2.exe and context.c
> The backtraces of the crash are attached in 12929 which is a general > catch all for the ATI issues. Well, no. 12929 is about a rather specific problem where fglrx crashes when trying to use GL_ATI_envmap_bumpmap or GL_ATI_separate_stencil. (And for what it's worth, that bug won't go anywhere until someone does what I asked in comment #57 and tries to reproduce it outside of wine.)
Re: EverQuest2.exe and context.c
Vitaliy Margolen wrote:
> Chris Ahrendt wrote:
>> Vitaliy Margolen wrote:
>>> Chris Ahrendt wrote:
Vitaliy Margolen wrote:
> Chris Ahrendt wrote:
>> Vitaliy Margolen wrote:
>>> Chris Ahrendt wrote:
Ok I ran make test and got the failure without running
Everquest2.exe let me attach the output of maketest. I guess
thats a start eh?
>>> You getting off-topic too far here. Make test have nothing to do
>>> with your game. Especially that you attached complete output of
>>> everything.
>>>
>>> However this lines tell the whole story:
libGL error: drmMap of framebuffer failed (Cannot allocate memory)
libGL error: reverting to (slow) indirect rendering
>>>
>>> You have broken driver. And I'm afraid your configuration can not
>>> be supported. You could try and read the faq about how to try and
>>> fix it. But that still won't fix broken driver.
>>>
>>> Vitaliy
>>>
>>> PS:
>>> Please do not attach big files to mailing list. If you are asked
>>> for them - send to that person directly or attach to the bug report.
>>>
>>> PPS:
>>> Please take this discussion to the bug report. It's not a general
>>> case but a game specific. It belongs there not in the developer's
>>> mailing list. Since you are not a developer yourself and just add
>>> an extra noise to the mailing list.
>> Actually Vialiy it is a discussion that belongs here... not in bug
>> fix..
>> I have had that gl error and its not what we are working on... the
>> problem we are working on was first found in EverQuest2.exe but I
>> was able to reproduce it without everquest. so its not a game
>> related issue.
>> Second point.. I was told to bring this sort of discussion over
>> here to
>> discuss as the patch list is not for general discussion.
>>
>
> I'm talking about bugzilla. What's the bug number you are referring
> too?
>
>
> Vitaliy.
There are a couple 14072 is one of them...
>>>
>>> Did you noticed that your patch has nothing to do with what you
>>> talking about here? The bug related to this topic is 14000. And
>>> please don't mix and match multiple things.
>>>
>>> Reading this thread you talking about:
>>> 1. Changing gotos with something
>>> 2. Not liking the code
>>> 3. PixelFormat.
>>> 4. make test failures (not even related to d3d at all)
>>> 5. dxdiag crash
>>>
>>> This is all on top of broken configuration (did you disable fast
>>> tls?) and known bad drivers and particular bad video card.
>>>
>>>
>>> Please stay on topic of pixelformat related problem or you won't get
>>> anywhere trying to fix everything at the same time.
>>>
>>> For the main topic - you will need to wait for Roderic to chime in on
>>> the reasons behind his code. This area is really fragile and should
>>> not be changed to fix a particular program.
>>>
>>> Vitaliy.
>> Yes I disabled fast tls... configuration is not broken...
> The message from the libGL indicates it is.
>
>> the thread was different for each of the topics... I never said I
>> didnt like the code.. if you read where I commented back to stefan I
>> said how
>
>> I am allowed a personal opinion and respect others opinions.
> Nothing wrong about that. And you've been told what is the Wine hackers
> opinion about gotos. That's all. The hardest part in this project is to
> getting used to how things work here.
>
>> I asked stefan where to go next when we were I did some research and
>> found make test so I ran that. When I ran that I recieved the same
>> problem I was experiencing with everquest.
> You ran all the tests. Which line out of the 100s of lines you attached
> indicate you got the same problem?
>
>> Never had a dxdiag crash so you must be mistaking me for someone else.
>
> Bug 14072 Wine Crashes with a Stack dump:
>
>> This patches the stack dump which occurs with Direct X games in Wine
>> on ATI
>>
>> --- provider.c2008-07-15 11:56:57.0 -0400
>> +++ provider_orig.c 2008-07-11 11:55:55.0 -0400
>> @@ -665,11 +665,7 @@ static HRESULT DXDiag_InitDXDiagDirectSh
>> }
>> IPropertyBag_Release(pPropFilterBag); pPropFilterBag = NULL;
>> }
>> - if (pEnum != NULL) -{ -
>> IEnumMoniker_Release(pEnum); - pEnum = NULL;
>> - }
>> + IEnumMoniker_Release(pEnum); pEnum = NULL;
>>}
>> class_enum_failed: SysFreeString(wszCatName);
>
> That's the patch for dxdign.dll since nothing else has provider.c. Or
> you pointed to the wrong bug?
>
>> But my card is not bad..
> Your card known to have hardware defect in it aggravated by the poor
> quality drivers. You can search bugzilla if you want more details. The
> point is you want to Wine developers to fix something that's broken
> somewhere else.
>
>
>> Can we all just quit with the your card is crap stuff and your driver
>
Re: EverQuest2.exe and context.c
Chris Ahrendt wrote:
> Vitaliy Margolen wrote:
>> Chris Ahrendt wrote:
>>> Vitaliy Margolen wrote:
Chris Ahrendt wrote:
> Vitaliy Margolen wrote:
>> Chris Ahrendt wrote:
>>> Ok I ran make test and got the failure without running
>>> Everquest2.exe let me attach the output of maketest. I guess
>>> thats a start eh?
>>>
>> You getting off-topic too far here. Make test have nothing to do
>> with your game. Especially that you attached complete output of
>> everything.
>>
>> However this lines tell the whole story:
>>> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
>>> libGL error: reverting to (slow) indirect rendering
>>
>> You have broken driver. And I'm afraid your configuration can not
>> be supported. You could try and read the faq about how to try and
>> fix it. But that still won't fix broken driver.
>>
>> Vitaliy
>>
>> PS:
>> Please do not attach big files to mailing list. If you are asked
>> for them - send to that person directly or attach to the bug report.
>>
>> PPS:
>> Please take this discussion to the bug report. It's not a general
>> case but a game specific. It belongs there not in the developer's
>> mailing list. Since you are not a developer yourself and just add
>> an extra noise to the mailing list.
> Actually Vialiy it is a discussion that belongs here... not in bug
> fix..
> I have had that gl error and its not what we are working on... the
> problem we are working on was first found in EverQuest2.exe but I
> was able to reproduce it without everquest. so its not a game
> related issue.
> Second point.. I was told to bring this sort of discussion over
> here to
> discuss as the patch list is not for general discussion.
>
I'm talking about bugzilla. What's the bug number you are referring
too?
Vitaliy.
>>> There are a couple 14072 is one of them...
>>>
>>
>> Did you noticed that your patch has nothing to do with what you
>> talking about here? The bug related to this topic is 14000. And please
>> don't mix and match multiple things.
>>
>> Reading this thread you talking about:
>> 1. Changing gotos with something
>> 2. Not liking the code
>> 3. PixelFormat.
>> 4. make test failures (not even related to d3d at all)
>> 5. dxdiag crash
>>
>> This is all on top of broken configuration (did you disable fast tls?)
>> and known bad drivers and particular bad video card.
>>
>>
>> Please stay on topic of pixelformat related problem or you won't get
>> anywhere trying to fix everything at the same time.
>>
>> For the main topic - you will need to wait for Roderic to chime in on
>> the reasons behind his code. This area is really fragile and should
>> not be changed to fix a particular program.
>>
>> Vitaliy.
> Yes I disabled fast tls... configuration is not broken...
The message from the libGL indicates it is.
> the thread was different for each of the topics... I never said I didnt
> like the code.. if you read where I commented back to stefan I said how
> I am allowed a personal opinion and respect others opinions.
Nothing wrong about that. And you've been told what is the Wine hackers
opinion about gotos. That's all. The hardest part in this project is to
getting used to how things work here.
> I asked stefan where to go next when we were
> I did some research and found make test so I ran that. When I ran that I
> recieved the same problem I was experiencing with everquest.
You ran all the tests. Which line out of the 100s of lines you attached
indicate you got the same problem?
> Never had a dxdiag crash so you must be mistaking me for someone else.
Bug 14072 Wine Crashes with a Stack dump:
> This patches the stack dump which occurs with Direct X games in Wine on ATI
>
> --- provider.c2008-07-15 11:56:57.0 -0400
> +++ provider_orig.c 2008-07-11 11:55:55.0 -0400
> @@ -665,11 +665,7 @@ static HRESULT DXDiag_InitDXDiagDirectSh
> }
> IPropertyBag_Release(pPropFilterBag); pPropFilterBag = NULL;
> }
> - if (pEnum != NULL)
> -{
> - IEnumMoniker_Release(pEnum);
> - pEnum = NULL;
> - }
> + IEnumMoniker_Release(pEnum); pEnum = NULL;
>}
> class_enum_failed:
>SysFreeString(wszCatName);
That's the patch for dxdign.dll since nothing else has provider.c. Or you
pointed to the wrong bug?
> But my card is not bad..
Your card known to have hardware defect in it aggravated by the poor quality
drivers. You can search bugzilla if you want more details. The point is you
want to Wine developers to fix something that's broken somewhere else.
> Can we all just quit with the your card is crap stuff and your driver is
> crap.. yes WE HAVE BEEN MADE AWARE OF THE FACT. I just want to fix the
> problem.
Then you are in the wrong place. You should be tal
Re: EverQuest2.exe and context.c
Vitaliy Margolen wrote: > Chris Ahrendt wrote: >> Vitaliy Margolen wrote: >>> Chris Ahrendt wrote: Vitaliy Margolen wrote: > Chris Ahrendt wrote: >> Ok I ran make test and got the failure without running >> Everquest2.exe let me attach the output of maketest. I guess thats >> a start eh? >> > You getting off-topic too far here. Make test have nothing to do > with your game. Especially that you attached complete output of > everything. > > However this lines tell the whole story: >> libGL error: drmMap of framebuffer failed (Cannot allocate memory) >> libGL error: reverting to (slow) indirect rendering > > You have broken driver. And I'm afraid your configuration can not > be supported. You could try and read the faq about how to try and > fix it. But that still won't fix broken driver. > > Vitaliy > > PS: > Please do not attach big files to mailing list. If you are asked > for them - send to that person directly or attach to the bug report. > > PPS: > Please take this discussion to the bug report. It's not a general > case but a game specific. It belongs there not in the developer's > mailing list. Since you are not a developer yourself and just add > an extra noise to the mailing list. Actually Vialiy it is a discussion that belongs here... not in bug fix.. I have had that gl error and its not what we are working on... the problem we are working on was first found in EverQuest2.exe but I was able to reproduce it without everquest. so its not a game related issue. Second point.. I was told to bring this sort of discussion over here to discuss as the patch list is not for general discussion. >>> >>> I'm talking about bugzilla. What's the bug number you are referring too? >>> >>> >>> Vitaliy. >> There are a couple 14072 is one of them... >> > > Did you noticed that your patch has nothing to do with what you talking > about here? The bug related to this topic is 14000. And please don't mix > and match multiple things. > > Reading this thread you talking about: > 1. Changing gotos with something > 2. Not liking the code > 3. PixelFormat. > 4. make test failures (not even related to d3d at all) > 5. dxdiag crash > > This is all on top of broken configuration (did you disable fast tls?) > and known bad drivers and particular bad video card. > > > Please stay on topic of pixelformat related problem or you won't get > anywhere trying to fix everything at the same time. > > For the main topic - you will need to wait for Roderic to chime in on > the reasons behind his code. This area is really fragile and should not > be changed to fix a particular program. > > Vitaliy. Yes I disabled fast tls... configuration is not broken... the thread was different for each of the topics... I never said I didnt like the code.. if you read where I commented back to stefan I said how about this version of his fix instead. Then I asked in another thread about the goto's and fixing those.. Where I found a goto that did just a return and nothing else... The other point was a goto changing that to a subroutine and then was explained to me that certain points gotos had to be used. Show me where I said I didnt like the code... I said I disliked goto's which is true.. I am allowed a personal opinion and respect others opinions. I asked stefan where to go next when we were working on his fix thats when I was trying to find something which I could run which he could run as well without having everquest. I did some research and found make test so I ran that. When I ran that I recieved the same problem I was experiencing with everquest. So I let him know that the error could be reproduced using something other than that. Never had a dxdiag crash so you must be mistaking me for someone else. Secondly unlike your tone I have not gotten snitty about things... and I don't appreciate that. Did you ever think to look and see how you come across? I try to considering this is an international list. I realise that the ATI drivers are flaky at best.. But my card is not bad.. I also have no choice as to what video card that is in my laptop.. this is not a desktop. I personally am, and others as well are tired of the you have crap get the hell out of here excuse. I am trying to work at fixing the problem not complaining about the problem but FIX it... I am not trying to fix everything at the same time as I said.. the above is the timeline of what occured which is all related to the pixel format issue. Can we all just quit with the your card is crap stuff and your driver is crap.. yes WE HAVE BEEN MADE AWARE OF THE FACT. I just want to fix the problem. Wine should not be getting an unhandled exception when it tries to initialise.. at worst it should throw an error. If it can not find a pixelshader... where is it... Once we look a
Re: EverQuest2.exe and context.c
Chris Ahrendt wrote: > Vitaliy Margolen wrote: >> Chris Ahrendt wrote: >>> Vitaliy Margolen wrote: Chris Ahrendt wrote: > Ok I ran make test and got the failure without running > Everquest2.exe let me attach the output of maketest. I guess thats > a start eh? > You getting off-topic too far here. Make test have nothing to do with your game. Especially that you attached complete output of everything. However this lines tell the whole story: > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering You have broken driver. And I'm afraid your configuration can not be supported. You could try and read the faq about how to try and fix it. But that still won't fix broken driver. Vitaliy PS: Please do not attach big files to mailing list. If you are asked for them - send to that person directly or attach to the bug report. PPS: Please take this discussion to the bug report. It's not a general case but a game specific. It belongs there not in the developer's mailing list. Since you are not a developer yourself and just add an extra noise to the mailing list. >>> Actually Vialiy it is a discussion that belongs here... not in bug fix.. >>> I have had that gl error and its not what we are working on... the >>> problem we are working on was first found in EverQuest2.exe but I was >>> able to reproduce it without everquest. so its not a game related issue. >>> Second point.. I was told to bring this sort of discussion over here to >>> discuss as the patch list is not for general discussion. >>> >> >> I'm talking about bugzilla. What's the bug number you are referring too? >> >> >> Vitaliy. > There are a couple 14072 is one of them... > Did you noticed that your patch has nothing to do with what you talking about here? The bug related to this topic is 14000. And please don't mix and match multiple things. Reading this thread you talking about: 1. Changing gotos with something 2. Not liking the code 3. PixelFormat. 4. make test failures (not even related to d3d at all) 5. dxdiag crash This is all on top of broken configuration (did you disable fast tls?) and known bad drivers and particular bad video card. Please stay on topic of pixelformat related problem or you won't get anywhere trying to fix everything at the same time. For the main topic - you will need to wait for Roderic to chime in on the reasons behind his code. This area is really fragile and should not be changed to fix a particular program. Vitaliy.
Re: EverQuest2.exe and context.c
Chris Ahrendt wrote: > Vitaliy Margolen wrote: >> Chris Ahrendt wrote: >>> Ok I ran make test and got the failure without running Everquest2.exe >>> let me attach the output of maketest. I guess thats a start eh? >>> >> You getting off-topic too far here. Make test have nothing to do with >> your game. Especially that you attached complete output of everything. >> >> However this lines tell the whole story: >>> libGL error: drmMap of framebuffer failed (Cannot allocate memory) >>> libGL error: reverting to (slow) indirect rendering >> >> You have broken driver. And I'm afraid your configuration can not be >> supported. You could try and read the faq about how to try and fix it. >> But that still won't fix broken driver. >> >> Vitaliy >> >> PS: >> Please do not attach big files to mailing list. If you are asked for >> them - send to that person directly or attach to the bug report. >> >> PPS: >> Please take this discussion to the bug report. It's not a general case >> but a game specific. It belongs there not in the developer's mailing >> list. Since you are not a developer yourself and just add an extra >> noise to the mailing list. > Actually Vialiy it is a discussion that belongs here... not in bug fix.. > I have had that gl error and its not what we are working on... the > problem we are working on was first found in EverQuest2.exe but I was > able to reproduce it without everquest. so its not a game related issue. > Second point.. I was told to bring this sort of discussion over here to > discuss as the patch list is not for general discussion. > I'm talking about bugzilla. What's the bug number you are referring too? Vitaliy.
Re: EverQuest2.exe and context.c
Vitaliy Margolen wrote: > Chris Ahrendt wrote: >> Ok I ran make test and got the failure without running Everquest2.exe >> let me attach the output of maketest. I guess thats a start eh? >> > You getting off-topic too far here. Make test have nothing to do with > your game. Especially that you attached complete output of everything. > > However this lines tell the whole story: >> libGL error: drmMap of framebuffer failed (Cannot allocate memory) >> libGL error: reverting to (slow) indirect rendering > > You have broken driver. And I'm afraid your configuration can not be > supported. You could try and read the faq about how to try and fix it. > But that still won't fix broken driver. > > Vitaliy > > PS: > Please do not attach big files to mailing list. If you are asked for > them - send to that person directly or attach to the bug report. > > PPS: > Please take this discussion to the bug report. It's not a general case > but a game specific. It belongs there not in the developer's mailing > list. Since you are not a developer yourself and just add an extra noise > to the mailing list. Actually Vialiy it is a discussion that belongs here... not in bug fix.. I have had that gl error and its not what we are working on... the problem we are working on was first found in EverQuest2.exe but I was able to reproduce it without everquest. so its not a game related issue. Second point.. I was told to bring this sort of discussion over here to discuss as the patch list is not for general discussion. Chris
Re: EverQuest2.exe and context.c
Chris Ahrendt wrote: > Ok I ran make test and got the failure without running Everquest2.exe > let me attach the output of maketest. I guess thats a start eh? > You getting off-topic too far here. Make test have nothing to do with your game. Especially that you attached complete output of everything. However this lines tell the whole story: > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering You have broken driver. And I'm afraid your configuration can not be supported. You could try and read the faq about how to try and fix it. But that still won't fix broken driver. Vitaliy PS: Please do not attach big files to mailing list. If you are asked for them - send to that person directly or attach to the bug report. PPS: Please take this discussion to the bug report. It's not a general case but a game specific. It belongs there not in the developer's mailing list. Since you are not a developer yourself and just add an extra noise to the mailing list.
RE: EverQuest2.exe and context.c
> Ok I did a clean install.. rebuilt wine from the base 1.1.1 code put
> the above patch into the context.c and reran EverQuest2.exe I put
> export WINEDEBUG=+d3d,+sed before running and am attaching the trace.
> (If you need more just send me a message and I will retry it.
> I still get the card does not have pixel shader error (and yes the card
> has pixel shaders (its an ATI FIREGL5200)). I am attaching the log and
> the screenshot.
Don't let yourself be fooled by the pixelshader error message. It most
likely has nothing to do with pixel shaders at all. Most likely the game
does something like this:
try {
do_init_1();
do_init_2();
do_init_3();
} catch(all_stuff_that_can_go_wrong) {
/* Initialization fails. This usually means that the card doesn't have
the features
* we need
*/
MessageBox("NO PIXEL SHADERS! GO BUY A BETTER CARD!!11!1!!\n");
}
Of course the app isn't prepared for other things to go wrong, e.g. a Wine
bug or a driver bug, and fails to write as much details about the problem as
it can. Writing proper error paths is a pain in the ass, and so on.
wine: Unhandled page fault on read access to 0x016c6580 at address 0xa3502f
(thread 0021), starting debugger..
This line is much more suspicious. The app seems to crash somewhere, and as
far as I can see in the log long after initializing the opengl context. It
does a reset call, but the Reset call succeeds. If changing the pixel format
loading changes the behavior, it's most likely because it avoids triggering
some crash in the graphics driver(doesn't mean it is a driver bug though).
RE: EverQuest2.exe and context.c
> why not remove this and go ahead and call ChoosePixelFormat? > If ChoosePixelFormat fails then we say we can't find a suitable pixel > format? This removes one problem when EverQuest2.exe runs where I get > 2-3 calls to WineD3D_ChoosePixelFormat Roderick has written this code, and he is on vacation right now. One of our rules is not to do any change to the code that happens to fix an app without doubt-free understanding of what the problem is. (Sometimes we have to make exceptions, e.g. with random graphics driver bugs) As far as I understand it, findCompatible is set when an onscreen drawable is created(drawing to a window), and it is FALSE if a pbuffer is created(one form of offscreen rendering). pbuffers aren't created at device creation or reset time, so something seems odd that removing the !findCompatible fixes a startup crash(unless the app instantly tries to do offscreen rendering and you have offscreenRenderingMode = pbuffer) The reason for not accepting compatible formats with pbuffers is(among others maybe) that rendering on a different format and then copying it to a texture can cause serious performance problems. So the !findCompatible in this code looks correct to me, but maybe the caller sets the flag incorrectly. Also it seems strange that this patch fixes a problem that is caused by recursive Reset() calls. I sent a patch to make the pixel format check less picky(especially regarding AUX buffers). I lost your reply to it, and Alexandre didn't apply it yet, I think due to your unanswered concern about it. Does that patch fix the problem with the game? The patch I mean is this: http://www.winehq.org/pipermail/wine-patches/2008-July/058282.html
