June 2012 - Wine-Devel - list.winehq.org

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > On Wed, Jun 06, 2012 at 11:56:06AM +0200, Jacek Caban wrote: >> On 06/06/12 11:52, Alexandre Julliard wrote: >> > Jacek Caban <jacek(a)codeweavers.com> writes: >> > >> >> This usage of list is broken here as well. list_init should be called >> >> before list_add_head (so calling it early in initialization code will >> >> fix both problems). >> > There's no reason to call list_init on list entries, it should only be >> > called on the actual list. >> >> Oh, right, sorry for misleading. I made wrong assumptions looking at the >> patch. > > So, Alexandre, is my patch right or wrong? And if wrong, can you quickly fix it:) The patch would work, but it's not very clean. It's better to avoid destroying objects that are not yet on the list. I have some more cleanups for that code that should address the issue. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2012

Re: Wine's support for reporting calling conventions

by Roger Cruz

Hi Eric, Thanks for replying. I saw that in the DWARF spec and I was afraid that DWARF may not provide detailed Info. But I also read in the spec that the compilers use a DWARF extension feature to convey additional info such as calling convention for each routine. Is there a way to coax GCC to output that information? Maybe thru a target plugin? Thanks Roger On Jun 6, 2012, at 3:06 AM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > that's a limitation of dwarf format (IIRC, from the specs, you have > either the default CC for your programming language/ABI, or a specific > one without defining it further) > FYII, the codeview format reports correctly this information > note also that winedbg doesn't support calling functions in the > debuggee, so this information is actually not used in winedbg > A+ > > 2012/6/6, Roger Cruz <roger_r_cruz(a)yahoo.com>: >> >> >> In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to >> hard-code the calling convention to CALL_FAR_C. Does Wine not support >> reporting a function's calling convention correctly then? Is it a >> limitation of DWARF or just that it is not implemented? I can see that >> DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL >> with objdump, it does not show this field in use. >> >> >> /* FIXME: assuming C source code */ >> sig_type = symt_new_function_signature(ctx->module, ret_type, >> CV_CALL_FAR_C); >> >> >> Thanks >> Roger >> > > > -- > -- > Eric Pouech

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Marcus Meissner

On Wed, Jun 06, 2012 at 11:56:06AM +0200, Jacek Caban wrote: > On 06/06/12 11:52, Alexandre Julliard wrote: > > Jacek Caban <jacek(a)codeweavers.com> writes: > > > >> This usage of list is broken here as well. list_init should be called > >> before list_add_head (so calling it early in initialization code will > >> fix both problems). > > There's no reason to call list_init on list entries, it should only be > > called on the actual list. > > Oh, right, sorry for misleading. I made wrong assumptions looking at the > patch. So, Alexandre, is my patch right or wrong? And if wrong, can you quickly fix it:) Ciao, Marcus

June 6, 2012

Re: [PATCH 3/5] d3drm: Handle texture associated with the materail when loading a mesh.

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/d3drm/meshbuilder.c | 37 +++++++++++++++++++++++++++++++++++++ > 1 files changed, 37 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M d3drm.dll -T ../../.. -p d3drm_test.exe.so d3drm.c && touch d3drm.ok d3drm.c:375: Test failed: No texture should be present wine: Unhandled page fault on write access to 0x00162708 at address 0x68353cb7 (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Jacek Caban

On 06/06/12 11:52, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> This usage of list is broken here as well. list_init should be called >> before list_add_head (so calling it early in initialization code will >> fix both problems). > There's no reason to call list_init on list entries, it should only be > called on the actual list. Oh, right, sorry for misleading. I made wrong assumptions looking at the patch. Jacek

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > This usage of list is broken here as well. list_init should be called > before list_add_head (so calling it early in initialization code will > fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Jacek Caban

On 06/06/12 11:34, Marcus Meissner wrote: > On Wed, Jun 06, 2012 at 11:31:52AM +0200, Jacek Caban wrote: >> Hi Marcus, >> >> On 06/06/12 10:17, Marcus Meissner wrote: >>> Hi, >>> >>> wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. >>> >>> The list is just not setup yet as we fail... >>> >>> Ciao, Marcus >>> --- >>> dlls/shell32/control.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c >>> index cb080d5..b3eddb6 100644 >>> --- a/dlls/shell32/control.c >>> +++ b/dlls/shell32/control.c >>> @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) >>> } >>> if (applet->proc) applet->proc(applet->hWnd, CPL_EXIT, 0L, 0L); >>> FreeLibrary(applet->hModule); >>> - list_remove( &applet->entry ); >>> + if (applet->entry.next) list_remove( &applet->entry ); >>> HeapFree(GetProcessHeap(), 0, applet->cmd); >>> HeapFree(GetProcessHeap(), 0, applet); >>> } >> The way Wine standard list implementation works, it should not be NULL >> here. It seems that list_init call is missing where the CPlApplet is >> allocated. > The error handling that calls this leaves the Control_LoadApplet function before it is attached to the > list head. > > list_add_head( &panel->applets, &applet->entry ); > > is not called before leaving the function. > No other list_ functions are used by Control_LoadApplet. > > Not sure if this is right, or if there should be a entry init? This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). Cheers, Jacek

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Marcus Meissner

On Wed, Jun 06, 2012 at 11:31:52AM +0200, Jacek Caban wrote: > Hi Marcus, > > On 06/06/12 10:17, Marcus Meissner wrote: > > Hi, > > > > wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. > > > > The list is just not setup yet as we fail... > > > > Ciao, Marcus > > --- > > dlls/shell32/control.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c > > index cb080d5..b3eddb6 100644 > > --- a/dlls/shell32/control.c > > +++ b/dlls/shell32/control.c > > @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) > > } > > if (applet->proc) applet->proc(applet->hWnd, CPL_EXIT, 0L, 0L); > > FreeLibrary(applet->hModule); > > - list_remove( &applet->entry ); > > + if (applet->entry.next) list_remove( &applet->entry ); > > HeapFree(GetProcessHeap(), 0, applet->cmd); > > HeapFree(GetProcessHeap(), 0, applet); > > } > > The way Wine standard list implementation works, it should not be NULL > here. It seems that list_init call is missing where the CPlApplet is > allocated. The error handling that calls this leaves the Control_LoadApplet function before it is attached to the list head. list_add_head( &panel->applets, &applet->entry ); is not called before leaving the function. No other list_ functions are used by Control_LoadApplet. Not sure if this is right, or if there should be a entry init? Ciao, Marcus

June 6, 2012

Re: [PATCH] shell32: do not crash "wine control.exe nonexisting"

by Jacek Caban

Hi Marcus, On 06/06/12 10:17, Marcus Meissner wrote: > Hi, > > wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. > > The list is just not setup yet as we fail... > > Ciao, Marcus > --- > dlls/shell32/control.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c > index cb080d5..b3eddb6 100644 > --- a/dlls/shell32/control.c > +++ b/dlls/shell32/control.c > @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) > } > if (applet->proc) applet->proc(applet->hWnd, CPL_EXIT, 0L, 0L); > FreeLibrary(applet->hModule); > - list_remove( &applet->entry ); > + if (applet->entry.next) list_remove( &applet->entry ); > HeapFree(GetProcessHeap(), 0, applet->cmd); > HeapFree(GetProcessHeap(), 0, applet); > } The way Wine standard list implementation works, it should not be NULL here. It seems that list_init call is missing where the CPlApplet is allocated. Cheers, Jacek

June 6, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Max TenEyck Woodbury

On 06/05/2012 01:16 PM, James Eder wrote: >>> >>> You obviously have absolutely no idea what the wine-mono package is for. >>> You should read up and apologize. >>> >>> >> NO APOLOGY! You are missing the point. >> > > You are missing the point. You're argument lacks weight because you > clearly have no idea what you're talking about. One cannot base a > reasonable argument on top of displays of ignorance and irrationality. > You can try but in the end you only look like an ass. I understand > that you're very passionate about the subject but understand that such > displays harm your cause more than help it. > > You were wrong on several technical details which you based several > key points of your argument on. A reasonable thing to do would be to > offer an apology while moving on to other points you feel more sure > about. Instead you respond with more rudeness. > > At this point I don't think you can recover well enough to have a > meaningful discussion. You should make a strategic withdrawal, do > some research, and reform your argument. > It is not so much the technical details that are the problem. It is the LEGAL problems and potential legal problems that are at the root of my complaint. Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed. I find it very frustrating that the technical points are made over and over as if they were somehow answers to the legal and strategic problems. If you think I have been rude, consider that ignoring the more important issues that I am trying to raise is equally if not more rude. If I have resorted to name calling or personal characterizations, then I do owe you all an apology, but I do not apologize for trying to get the non-technical aspects of the problem presented.

June 5, 2012