December 2004 - Wine-Devel - list.winehq.org

Re: build problem on current cvs

by Michael Stefaniuc

Stefan Leichter wrote: > this problem confuses me. I have started regession testing. It turn out to be > a problem of 'out of tree' builds and the name of the directory containing > the cvs tree. If i use the cvs tree as checked out from winehq widl crashes. > If i rename the main directory wine of the cvs tree to wine-saved1 widl > works. It looks like the length of the name makes this difference wine-123456 > works also. Shorter names crash widl but in different files. If i build wine > in the cvs tree itself it works too. I'm doing only out of tree builds and my source directories are named wine. But my path to those wine directories are longer than yours. One is an absolute path (different file systems) the other two directory layers more then yours (-I../../../source/wine/include). I never encountered a crash. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Christian Costa

> >> >> @@ -1191,7 +1287,9 @@ >> OAFilterState *pfs) { >> ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >> >> - TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, >> pfs); >> + TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, >> msTimeout, pfs); >> + >> + *pfs = This->state; >> >> >> > > This probably needs protection too. > I saw you also did this for filesource and avi splitter filters. What do you want to prevent here? Bye, Christian

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph (take 2)

by Robert Shearman

Christian Costa wrote: > Hi, > > This time with more thread safety. Looking better, but one more change needed. In addition, most of the code in filtergraph.c isn't thread safe. Thread safety is particularly important in DirectShow where threads are heavily used. Debugging random crashes is not fun. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); >+ >+ if (This->state == State_Running) >+ return S_OK; > > > This should be inside the critical section, being careful, of course, not to return without calling LeaveCriticalSection. >+ EnterCriticalSection(&This->cs); >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ >+ LeaveCriticalSection(&This->cs); >+ > return S_FALSE; > } > > Rob

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Robert Shearman

Christian Costa wrote: >> >>> >>> @@ -1191,7 +1287,9 @@ >>> OAFilterState *pfs) { >>> ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >>> >>> - TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, >>> pfs); >>> + TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, >>> msTimeout, pfs); >>> + >>> + *pfs = This->state; >>> >>> >>> >> >> This probably needs protection too. >> > > I saw you also did this for filesource and avi splitter filters. > What do you want to prevent here? Partial updates and potential code that depends on the state not changing in a function. Rob

Dec. 29, 2004

Re: another build problem on current cvs

by Joris Huizer

Vincent Béron wrote: > Le mar 28/12/2004 à 09:24, Joris Huizer a écrit : > >>Hello, >> >>For the past week or so, building from cvs on a debian/stable system w/ >>alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks >>on alsa-specific code in wine; >>I attached the log; note that I did a `cvs update -dPA` and `make >>distclean` so this can't be any problem with the source I have >> >>Any ideas? Maybe you can point me to a place where I can read how to fix >>this properly (I never worked on alsa-specific code before...) or >>something like that > > > Which version of ALSA do you have headers for? > > Vincent > > > > In debian the package is called libasound2-dev, version "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa Joris

Dec. 29, 2004

Re: build problem on current cvs

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 23:47 schrieb Jacek Caban: > Stefan Leichter wrote: > >Am Dienstag, 28. Dezember 2004 11:15 schrieb Jacek Caban: > >>Hi. > >> > >>Stefan Leichter wrote: > >>>Hello, > >>> > >>>i hope you all had nice Christmas. > >>> > >>>Now back to business :-) > >>> > >>>trying to build current cvs (~7:45 AM UTC) i get the error: > >>> > >>>make[1]: Entering directory `/usr/src/wine/wine-build/include' > >>>../tools/widl/widl -I../../wine/include -I. -I../../wine/include > >>>-I../include -h -H oaidl.h ../../wine/include/oaidl.idl > >>> > >>> > >>>../../wine/include/wtypes.idl:1: Oops, segment violation > >>>make[1]: *** [oaidl.h] Abgebrochen > >>>make[1]: *** Datei »oaidl.h« wird gelöscht > >>>make[1]: Leaving directory `/usr/src/wine/wine-build/include' > >>>make: *** [include] Fehler 2 > >>> > >>>My system is still SuSE 9.0. I am doing 'out of tree' builds. > >>> > >>>Bye Stefan > >> > >>Did you do make depend? > >> > >>Thanks, > >> Jacek > > > >this happens for me during make depend ;-) > > > >Thanks Stefan > > Could you try debug widl by gdb? Try: > $ gdb --args ../tools/widl/widl -I../../wine/include -I. > -I../../wine/include -I../include -h -H oaidl.h > ../../wine/include/oaidl.idl Hello, this problem confuses me. I have started regession testing. It turn out to be a problem of 'out of tree' builds and the name of the directory containing the cvs tree. If i use the cvs tree as checked out from winehq widl crashes. If i rename the main directory wine of the cvs tree to wine-saved1 widl works. It looks like the length of the name makes this difference wine-123456 works also. Shorter names crash widl but in different files. If i build wine in the cvs tree itself it works too. Logfile of gdb session attached. Thanks Stefan

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Robert Shearman

Christian Costa wrote: > Hi, > > Changelog: > Implemented IMediaControl_Run that explores the graph, counts > renderers and starts filters. > Better implementation of IBaseFilter_Run for AVI SPlitter and AVI > Decompressor. > Use the standard memory allocator when an output pin does not provide > any allocator. > Set allocator properties for AVI Decompressor output pin and update > the buffers size at connection time. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: dlls/quartz/avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.12 >diff -u -r1.12 avidec.c >--- dlls/quartz/avidec.c 27 Dec 2004 17:15:58 -0000 1.12 >+++ dlls/quartz/avidec.c 29 Dec 2004 09:06:24 -0000 >@@ -235,6 +235,9 @@ > pAVIDec->pBihOut->biCompression = 0; > pAVIDec->pBihOut->biSizeImage = pAVIDec->pBihOut->biWidth * pAVIDec->pBihOut->biHeight * pAVIDec->pBihOut->biBitCount / 8; > >+ /* Update buffer size of media samples in output */ >+ ((OutputPin*)pAVIDec->ppPins[1])->allocProps.cbBuffer = pAVIDec->pBihOut->biSizeImage; >+ > pAVIDec->init = 1; > TRACE("Connection accepted\n"); > return S_OK; >@@ -354,7 +357,13 @@ > > if (SUCCEEDED(hr)) > { >- hr = AVIDec_OutputPin_Construct(&piOutput, NULL, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); >+ ALLOCATOR_PROPERTIES props; >+ props.cbAlign = 1; >+ props.cbPrefix = 0; >+ props.cbBuffer = 0; /* Will be updated at connection time */ >+ props.cBuffers = 2; >+ >+ hr = AVIDec_OutputPin_Construct(&piOutput, &props, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); > > if (FAILED(hr)) > ERR("Cannot create output pin (%lx)\n", hr); >@@ -502,6 +511,8 @@ > This->state = State_Running; > } > LeaveCriticalSection(&This->csFilter); >+ >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[1]); > > This needs to be inside the critical section. > > return hr; > } >Index: dlls/quartz/avisplit.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avisplit.c,v >retrieving revision 1.10 >diff -u -r1.10 avisplit.c >--- dlls/quartz/avisplit.c 27 Dec 2004 17:15:58 -0000 1.10 >+++ dlls/quartz/avisplit.c 29 Dec 2004 09:06:26 -0000 >@@ -327,6 +327,7 @@ > { > HRESULT hr = S_OK; > AVISplitter *This = (AVISplitter *)iface; >+ int i; > > TRACE("(%s)\n", wine_dbgstr_longlong(tStart)); > >@@ -337,6 +338,17 @@ > } > LeaveCriticalSection(&This->csFilter); > >+ hr = PullPin_InitProcessing(This->pInputPin); >+ >+ if (SUCCEEDED(hr)) >+ { >+ for (i = 1; i < This->cStreams + 1; i++) >+ { >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[i]); >+ } >+ hr = PullPin_StartProcessing(This->pInputPin); >+ } >+ > return hr; > } > > And so does this. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >+ if (This->state == State_Running) >+ return S_OK; >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ > return S_FALSE; > } > > And this all needs to be protected by a critical section too. > >@@ -1191,7 +1287,9 @@ > OAFilterState *pfs) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); > >- TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, pfs); >+ TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, msTimeout, pfs); >+ >+ *pfs = This->state; > > > This probably needs protection too. Rob

Dec. 29, 2004

Re: UNICOWS: stub implementations

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 16:22 schrieb Hans Leidekker: > On Tuesday 28 December 2004 15:30, Stefan Leichter wrote: > > you missed to send the implementations of the stubs! > > Well, yes and no. Our unicows doesn't have any implementations itself, it > just links to the dlls that do have them by creating dummy references. For > those dlls I sent patches earlier, so indirectly I did implement the stubs > in unicows, see? > > -Hans Well ok, another brown paper bag for my collection. Stefan

Dec. 29, 2004

Re: lotus notes regression

by Paul R Streitman

Mike, Sorry about that, I edited away the notes level at some point! This is with notes 6.5.3. I can easily reproduce it if you would like me to try anything. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com Mike Hearn <mh(a)codeweavers.c om> To Sent by: wine-devel(a)winehq.com wine-devel-admin@ cc winehq.org Subject Re: lotus notes regression 12/28/2004 08:25 PM On Tue, 28 Dec 2004 19:21:27 -0500, Paul R Streitman wrote: > Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom > is a hang with the CPU at 100%, and it happens immediately if you try to > click on a notes 'bookmark', or shortly after you try to do much of > anything else if you try to avoid the 'bookmarks'. This is the following patch: Log message: Moved update region handling to the server. Patch: http://cvs.winehq.org/patch.py?id=14725 ie, it's a WM rewrite regression. I will investigate when I get a chance. Paul, is this Notes 6.5.1 or an earlier version? thanks -mike

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

Any news about the ptrace single-stepping breakage of wine? The application that stopped working for me is xst, the Xilinx HDL synthesizer (there's a free as in beer version at http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGl… ). I'm currently at kernel 2.6.10-ac1 (as packaged by Arjan van de Ven), and wine-20041201-1fc3winehq. Compiling vhdl file H:/sailer/src/vhdl/xxx/vprim.vhd in Library synwork. FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com Thanks, Tom

Dec. 29, 2004