May 2003 - Wine-Devel - list.winehq.org

Assertion `!sem->obj.head' failed in release_semaphore

by Rein Klazes

Hi, Starting newsbin with messages that where marked for download in a previous run ( so it will start downloading immediately at start-up) freezes after the main window is opened. The last lines of a +relay,+server trace are: | 0009:Call kernel32.ReleaseSemaphore(00000064,00000001,40732a14) ret=0041b55e | 0009: release_semaphore( handle=0x64, count=00000001 ) | wineserver: semaphore.c:96: release_semaphore: Assertion `!sem->obj.head' failed. (full 1.4 MB trace at http://www.xs4all.nl/~rklazes/temp/nb.log.bz2 ) Funny, even if the bug can be reproducebly triggered by a message that is to be downloaded ,nothing of this appears in the log: no winsock call is made. Trying with several old wines, reveals that this bug is at least 3 months old, apparently not related to the new threading code. I've searched through the trace and the server code (it must be a server bug, doesn't it?) but see nothing obviously wrong. Any suggestions? Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 1, 2003

Re: iphlpapi.dll--help! (take 2)

by Juan Lang

Prev guess about wrong ioctl being called was wrong. Looks like some kind of stack corruption, only when called from wsock32. iphlpapi works fine. I tried to trace what's up with some printouts. I have a stack variable ndx, and with code like: FIXME("ndx is %d, at %x\n", ndx, &ndx); ndx += 4; FIXME("ndx is %d, at %x\n", ndx, &ndx); I see output like: ndx is 0, at 40670b80 ndx is 101683072, at 40670b80 Umm.. anyone have any clues what's special about wsock32? I'll post code shortly for some kind soul to play with. --Juan --- "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote: > On Wed, 30 Apr 2003, Juan Lang wrote: > > > Email me if interested. No, it's not vaporware, > it's > > just not as well tested as I'd like. > > Just send it over to wine-devel for comments, or > wine-patches > for inclusion into the tree. > > -- > Dimi. > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

May 1, 2003

Re: rpc exception

by Gregory M. Turner

On Thursday 01 May 2003 01:42 am, Ove Kaaven wrote: > tor, 01.05.2003 kl. 07.26 skrev Gregory M. Turner: > > (b) if the exception code doesn't run, A() runs longjmp again, to > > non-local goto /back/ into D(), using the second jmp_buf. This returns > > normally and would, I guess, expect to unwind the stack normally through > > C(), B() and so on... (this is all ignoring the fact that flow-of-control > > was interrupted by an exception, but for my purposes I don't think it > > matters). > > This is not OK. Since the first setjmp releases all the stack frames > between A and D, trying to later reclaim that released stack with > another setjmp is doomed to unpredictable stack corruption. was afraid of that... bummer. well, back to the drawing board ;) I guess this is how we ended up with the need for a function in the first place -- you (seem to) need "lambda" delayed execution capabilities that aren't easily achieved by a macro... :( Say, Alexandre, would it be a possibility to just bake some magic into wpp for this? -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

May 1, 2003

Re: rpc exception

by Ove Kaaven

tor, 01.05.2003 kl. 07.26 skrev Gregory M. Turner: > (a) if the exception code runs, A() keeps running and eventually just > returns... will it properly release all the stack from B(), C() and so on or > is this a problem? I guess its OK since the SP just goes back to what it was > when I called setjmp, right? This would be OK. > (b) if the exception code doesn't run, A() runs longjmp again, to non-local > goto /back/ into D(), using the second jmp_buf. This returns normally and > would, I guess, expect to unwind the stack normally through C(), B() and so > on... (this is all ignoring the fact that flow-of-control was interrupted by > an exception, but for my purposes I don't think it matters). This is not OK. Since the first setjmp releases all the stack frames between A and D, trying to later reclaim that released stack with another setjmp is doomed to unpredictable stack corruption.

May 1, 2003

Re: rpc exception

by Gregory M. Turner

On Monday 21 April 2003 10:55 pm, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > Just like with threads, why not cross that bridge when we get there? > > Is it really worth it to penalize 99% of the people? When we port to > > another compiler, it will be a lot simpler to worry about those pieces > > of code, rather than have no code at all. > > The difference with threads is that we know all platforms have some > kind of threading, so we know that we can adapt the code when > needed. I don't think any other C compiler supports local functions > (even g++ doesn't AFAIK), so there won't be much hope of ever making > it work. Of course we could decide to stop supporting other compilers, > but I don't think everybody would be happy with that. > > > Also, not accepting code into Wine that depend on exception is one thing, > > but what about Winelib? We can have the exception code commented out if > > __WINESRC__ is defined, but at least lets get it in if it works, it will > > plug a big Winelib hole. > > Sure, we can make the macros available for Winelib. OK, folks, I think I may have a plan to create a portable __except, please let me know your thoughts, as there are many places I might be going wrong. What follows is a totally new approach compared to my old attempts; I haven't tried to implement a similar implementation "plan" for __finally yet. Allright, here goes, in crap / gibberish ("pseudocode") form: /* GLOBAL structure instance somewhere (ntdll?) Thread-local */ typedef struct { bool do_handler_bit; DWORD exception_code; jmp_buf jmp; } SEH_TLS_TEMP; SEH_TLS_TEMP SEH_TLS_TEMPS; WINE_EXCEPTION_HANDLER_FUNC WineSEHHandler(args) { if (setjmp(SEH_TLS_TEMPS.jmp)) { switch(SEH_TLS_TEMPS.exception_code) ... /* the rest is like __wine_exception_handler in ntdll/exception.c */ } else { do_handler_bit = 0; longjmp(exception_record_argument->jmpbuf, 0); } } /* now here are the parts that would be in include/wine/exception.h */ /* exactly the same as __TRY, really just #define __try __TRY */ #define __try \ do { __WINE_FRAME __f; \ int __first = 1; \ for (;;) if (!__first) \ { \ do { #define __except(expr) \ } while(0); \ SEH_TLS_TEMPS.do_handler_bit = 0; __wine_pop_frame( &__f.frame ); \ break; \ } else { \ __f.frame.Handler = (PEXCEPTION_HANDLER) WineSEHHandler; \ __f.u.filter = NULL; \ __wine_push_frame( &__f.frame ); \ if (setjmp( __f.jmp)) { \ int ecode; \ const __WINE_FRAME * const __eptr WINE_UNUSED = &__f; \ /* exception code hacks go here... */ \ if ((ecode = (expr)) != EXECUTE_HANDLER) { \ SEH_TLS_TEMPS.exception_code = ecode \ longjmp(SEH_TLS_TEMPS.jmp, 0); \ } \ RtlUnwind(...); \ __wine_pop_frame(); SEH_TLS_TEMPS.do_handler_bit = 1; \ break; \ } \ __first = 0; \ } \ } while (0); \ if (SEH_TLS_TEMPS.do_handler_bit) This obviously is leaving some stuff out. For example, this wouldn't work with nested exceptions. However, that seems possible to fix, if not by abusing the jmp_buf right in the frame structure then by creating a stack of SEH_TLS_TEMP structures instead of just a single instance, or maybe in some other clever way like attaching the SEH_TLS_TEMP struct to the wine frame struct. What I'm more concerned about is the following: A() runs setjmp, calls B(), which calls C(), which calls D(). A() would be the user's function (whatever it is) and D() would be WineSEHHandler above. D() runs setjmp again on a second jump buffer, and calls longjmp to do a nonlocal goto into A(). Now: (a) if the exception code runs, A() keeps running and eventually just returns... will it properly release all the stack from B(), C() and so on or is this a problem? I guess its OK since the SP just goes back to what it was when I called setjmp, right? (b) if the exception code doesn't run, A() runs longjmp again, to non-local goto /back/ into D(), using the second jmp_buf. This returns normally and would, I guess, expect to unwind the stack normally through C(), B() and so on... (this is all ignoring the fact that flow-of-control was interrupted by an exception, but for my purposes I don't think it matters). Are either of these scenarios illegal (in wine)? If not, I think I can make it work. Another concern would be that two longjmps are just too slow to be used, but since that only occurs in an exception scenario I think it's OK... Thoughts, flames, etc? -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

May 1, 2003

Re: wine/ tools/wrc/wrc.c tools/wrc/parser.y tools ...

by Dimitrie O. Paun

On April 30, 2003 11:16 pm, Alexandre Julliard wrote: > Moved the wpp library from tools/ to libs/. If we do this (which is great, yay!), why not rename it to wine_pp or wine_cpp for consistency with the other libs? We don't need to rename the libs/wpp dir, but what about the library itself? -- Dimi.

May 1, 2003

Re: $(RC) portability

by Dimitrie O. Paun

On April 29, 2003 09:03 pm, Alexandre Julliard wrote: > You can't remove the -o options, wrc cannot guess where the output > file should go. Of course, I don't know what I was thinking. I was tricked by the fact that I had the old .res already compiled in my build dir... Here it is again, with -fo instead of -o. ChangeLog Make it easy to use something other than wrc to compile resources. Index: Make.rules.in =================================================================== RCS file: /var/cvs/wine/Make.rules.in,v retrieving revision 1.155 diff -u -r1.155 Make.rules.in --- Make.rules.in 21 Apr 2003 23:54:06 -0000 1.155 +++ Make.rules.in 30 Apr 2003 21:37:04 -0000 @@ -62,10 +62,12 @@ RUNTEST = $(TOPSRCDIR)/tools/runtest WINEBUILD = $(TOOLSDIR)/tools/winebuild/winebuild MAKEDEP = $(TOOLSDIR)/tools/makedep -WRC = $(TOOLSDIR)/tools/wrc/wrc +RC = $(TOOLSDIR)/tools/wrc/wrc +RC16 = $(TOOLSDIR)/tools/wrc/wrc WMC = $(TOOLSDIR)/tools/wmc/wmc WIDL = $(TOOLSDIR)/tools/widl/widl -WRCFLAGS = --nostdinc $(INCLUDES) $(EXTRAWRCFLAGS) +RCFLAGS = --nostdinc $(INCLUDES) $(EXTRARCFLAGS) +RC16FLAGS = -O res16 $(RCFLAGS) LDPATH = @LDPATH@ DLLDIR = $(TOPOBJDIR)/dlls LIBPORT = -L$(TOPOBJDIR)/libs/port -lwine_port @@ -116,7 +118,7 @@ $(LDPATH) $(WMC) -i -U -H /dev/null -o $@ $< .rc.res: - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ $< + $(LDPATH) $(RC) $(RCFLAGS) -fo$@ $< .res.res.o: $(WINDRES) -i $< -o $@ @@ -247,9 +249,9 @@ # Misc. rules -$(RC_SRCS:.rc=.res): $(WRC) +$(RC_SRCS:.rc=.res): $(RC) -$(RC_SRCS16:.rc=.res): $(WRC) +$(RC_SRCS16:.rc=.res): $(RC) $(MC_SRCS:.mc=.mc.rc): $(WMC) Index: ./dlls/gdi/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/gdi/Makefile.in,v retrieving revision 1.50 diff -u -r1.50 Makefile.in --- ./dlls/gdi/Makefile.in 21 Apr 2003 23:54:06 -0000 1.50 +++ ./dlls/gdi/Makefile.in 30 Apr 2003 21:37:50 -0000 @@ -83,6 +83,6 @@ $(WINEBUILD) $(DEFS) -o $@ --heap 65520 --main-module $(MODULE) --res version16.res --spec $(SRCDIR)/gdi.exe.spec version16.res: version16.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/version16.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc ### Dependencies: Index: ./dlls/kernel/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/kernel/Makefile.in,v retrieving revision 1.64 diff -u -r1.64 Makefile.in --- ./dlls/kernel/Makefile.in 30 Apr 2003 00:53:23 -0000 1.64 +++ ./dlls/kernel/Makefile.in 30 Apr 2003 21:38:17 -0000 @@ -69,6 +69,6 @@ $(WINEBUILD) $(DEFS) -o $@ --dll-name kernel --main-module $(MODULE) --res version16.res --spec $(SRCDIR)/krnl386.exe.spec version16.res: version16.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/version16.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc ### Dependencies: Index: ./dlls/shell32/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/shell32/Makefile.in,v retrieving revision 1.65 diff -u -r1.65 Makefile.in --- ./dlls/shell32/Makefile.in 21 Apr 2003 23:54:06 -0000 1.65 +++ ./dlls/shell32/Makefile.in 29 Apr 2003 05:34:33 -0000 @@ -68,7 +68,7 @@ # Special rules for 16-bit resource files version16.res: version16.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/version16.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc shell.spec.c: shell.spec version16.res $(WINEBUILD) $(DEFS) -o $@ --main-module $(MODULE) --res version16.res --spec $(SRCDIR)/shell.spec Index: ./dlls/user/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/user/Makefile.in,v retrieving revision 1.69 diff -u -r1.69 Makefile.in --- ./dlls/user/Makefile.in 21 Apr 2003 23:54:05 -0000 1.69 +++ ./dlls/user/Makefile.in 30 Apr 2003 21:39:18 -0000 @@ -120,12 +120,12 @@ $(WINEBUILD) $(DEFS) -o $@ --main-module $(MODULE) --res resources/mouse.res --spec $(SRCDIR)/mouse.spec resources/display.res: resources/display.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/resources/display.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/resources/display.rc resources/mouse.res: resources/mouse.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/resources/mouse.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/resources/mouse.rc resources/version16.res: resources/version16.rc - $(LDPATH) $(WRC) $(WRCFLAGS) -o $@ -O res16 $(SRCDIR)/resources/version16.rc + $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/resources/version16.rc ### Dependencies: Index: ./programs/winhelp/Makefile.in =================================================================== RCS file: /var/cvs/wine/programs/winhelp/Makefile.in,v retrieving revision 1.34 diff -u -r1.34 Makefile.in --- ./programs/winhelp/Makefile.in 11 Dec 2002 01:34:51 -0000 1.34 +++ ./programs/winhelp/Makefile.in 26 Apr 2003 14:32:58 -0000 @@ -16,7 +16,7 @@ EXTRA_SRCS = macro.lex.l EXTRA_OBJS = @LEX_OUTPUT_ROOT(a).o -EXTRAWRCFLAGS = -DWINELIB +EXTRARCFLAGS = -DWINELIB RC_SRCS = rsrc.rc -- Dimi.

May 1, 2003

Re: iphlpapi.dll--help!

by Juan Lang

I've got iphlpapi.dll working reasonably well. The platform-specific functions I put in a new file, ipshared.c. I compile this into iphlpapi.dll, and I'm trying to compile it into wsock32, also. Problem is, when I call ioctl from ipshared.c compiled into wsock32, the ioctl that gets called is the winsock one, not the UNIX one. I could use ioctlsocket, but not every DLL that might compile ipshared.c uses this hack. (wsock32 does, ws_2 does not, netapi does not) I could export private functions from some DLL or other, but goes against the recent cleanup work that's been going on. Suggestions, anyone? Thanks, --Juan --- "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote: > On Wed, 30 Apr 2003, Juan Lang wrote: > > > Email me if interested. No, it's not vaporware, > it's > > just not as well tested as I'd like. > > Just send it over to wine-devel for comments, or > wine-patches > for inclusion into the tree. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

May 1, 2003

winsock on cygwin

by Steven Edwards

I dont know the proper way to test for this so I figured I would send it to wine-devel for comment also Index: socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.125 diff -u -r1.125 socket.c --- socket.c 9 Apr 2003 23:33:35 -0000 1.125 +++ socket.c 1 May 2003 01:40:53 -0000 @@ -275,6 +275,11 @@ { 0, 0 } }; +/* + * IP_HDRINCL fails is broken on Windows. + * See http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257460 + */ + static const int ws_ip_map[][2] = { MAP_OPTION( IP_MULTICAST_IF ), @@ -283,7 +288,9 @@ MAP_OPTION( IP_ADD_MEMBERSHIP ), MAP_OPTION( IP_DROP_MEMBERSHIP ), MAP_OPTION( IP_OPTIONS ), +#ifndef __CYGWIN__ MAP_OPTION( IP_HDRINCL ), +#endif MAP_OPTION( IP_TOS ), MAP_OPTION( IP_TTL ), { 0, 0 }

May 1, 2003