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

Re: SIGSEGV while trying to run Word97

by J. Cone

Does Wine still handle SIGSEGV to implement something like Windows memory management? At 10:47 15/06/01 +0200, Heiko Nardmann wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder >unzureichender Speicherplatz, um Word auszuführen" (German version). After >trying to examine this problem with debugmsg all (without real success) I >added an strace call to the whole call. This resulted in a log file which >tells me that a SIGSEGV occurrs. Here is a part of the strace log file which >contains the SIGSEGV message. After that the appropriate 'debugmsg all' part >follows. What can be done to shed more light onto this problem? > >strace log: > >write(2, "08069280:trace:win32:_LeaveSysLe"..., 112) = 112 >write(2, "08069280:Ret user32.CreateWindo"..., 68) = 68 >write(2, "08069280:RET mso97.486: _MsoCre"..., 84) = 84 >write(2, "08069280:trace:heap:HeapFree (40"..., 74) = 74 >write(2, "08069280:Call kernel32.GetVersio"..., 49) = 49 >write(2, "08069280:Ret kernel32.GetVersio"..., 65) = 65 >write(2, "08069280:Call kernel32.GetVersio"..., 60) = 60 >write(2, "08069280:Ret kernel32.GetVersio"..., 68) = 68 >write(2, "08069280:Call kernel32.GlobalMem"..., 65) = 65 >time(NULL) = 992531763 >time(NULL) = 992531763 >open("/proc/meminfo", O_RDONLY) = 11 >fstat(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 >old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) >= 0x4035c000 >read(11, " total: used: free:"..., 1024) = 319 >read(11, "", 1024) = 0 >close(11) = 0 >munmap(0x4035c000, 4096) = 0 >write(2, "08069280:Ret kernel32.GlobalMem"..., 73) = 73 >write(2, "08069280:CALL mso97.394: _MsoFCr"..., 147) = 147 >write(2, ") ret=30011010\n", 15) = 15 >write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 >write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 >mmap2(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS >(Function not implemented) >old_mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = >0x40e90000 >munmap(0x40ea0000, 65536) = 0 >write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 >write(2, " 40e90000 - 40e9ffff -----\n", 32) = 32 >write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 >write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 >write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 >write(2, "08069280:trace:virtual:VIRTUAL_S"..., 63) = 63 >mprotect(0x40e90000, 4096, PROT_READ|PROT_WRITE) = 0 >write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 >write(2, " 40e90000 - 40e90fff c-rW-\n", 32) = 32 >write(2, " 40e91000 - 40e9ffff -----\n", 32) = 32 >write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 >- --- SIGSEGV (Speicherzugriffsfehler) --- >write(2, "08069280:RET mso97.394: _MsoFCr"..., 126) = 126 >rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 >write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) > = 64 >read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 >write(2, "08069280:trace:seh:EXC_RtlUnwind"..., 55) = 55 >write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 >write(2, "08069280:trace:seh:EXC_CallHandl"..., 54) = 54 >- --- SIGSEGV (Speicherzugriffsfehler) --- >write(2, "08069280:trace:seh:EXC_RtlRaiseE"..., 63) = 63 >rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 >write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) > = 64 >read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > > >wine debug log: > >08069280:trace:win32:_LeaveSysLevel (0x40753a74, level 2): thread 0x8069280 >(fs 008f, pid 24063) count after 0 >08069280:Ret user32.CreateWindowExW() retval=00000138 ret=306cc216 >08069280:RET mso97.486: _MsoCreateMonitorWindow(a)0() retval = 00000000 >ret=3000162f >08069280:trace:heap:HeapFree (40360000,00000002,403a4a80): returning TRUE >08069280:Call kernel32.GetVersion() ret=30001984 >08069280:Ret kernel32.GetVersion() retval=05650004 ret=30001984 >08069280:Call kernel32.GetVersionExA(405c686c) ret=300019b5 >08069280:Ret kernel32.GetVersionExA() retval=00000001 ret=300019b5 >08069280:Call kernel32.GlobalMemoryStatus(405c6900) ret=300019e2 >08069280:Ret kernel32.GlobalMemoryStatus() retval=405c6900 ret=300019e2 >08069280:CALL mso97.394: _MsoFCreateIPref(a)28(<unknown, check >return>08069280:trace:heap:HeapAlloc (40360000,00000002,00000040): returning >403a4b98 >) ret=30011010 >08069280:Call kernel32.VirtualAlloc(00000000,0000fffc,00002000,00000001) >ret=3070b360 >08069280:trace:virtual:VirtualAlloc 00000000 0000fffc 2000 00000001 >View: 40e90000 - 40e9ffff (valloc) > 40e90000 - 40e9ffff ----- >08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b360 >08069280:Call kernel32.VirtualAlloc(40e90000,00001000,00001000,00000004) >ret=3070b38b >08069280:trace:virtual:VirtualAlloc 40e90000 00001000 1000 00000004 >08069280:trace:virtual:VIRTUAL_SetProt 40e90000-40e90fff c-rW- >View: 40e90000 - 40e9ffff (valloc) > 40e90000 - 40e90fff c-rW- > 40e91000 - 40e9ffff ----- >08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b38b >08069280:RET mso97.394: >_MsoFCreateIPref(a)28(30011020,00000000,08069280:trace:seh:EXC_RtlRaiseExcept ion >code=c0000005 flags=0 >08069280: queue_exception_event( first=1, >record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx= 00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8aca,esp=405c66cc,ef lags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000 000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,0000 0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 ,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,000 00000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000 0,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8aca,params={0, 4d535744}} >) >08069280: queue_exception_event() = 0 { handle=0 } >08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 >code=c0000005 flags=0 >08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 >08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 >code=c0000005 flags=2 >08069280:trace:seh:EXC_CallHandler handler returned 1 >08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 >08069280: queue_exception_event( first=1, >record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx= 00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8baa,esp=405c66cc,ef lags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000 000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,0000 0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 ,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,000 00000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000 0,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8baa,params={0, 4d535744}} >) >08069280: queue_exception_event() = 0 { handle=0 } >08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 >code=c0000005 flags=0 >08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 >08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 >code=c0000005 flags=2 >08069280:trace:seh:EXC_CallHandler handler returned 1 > >- -- >Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development >secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) >Weidenauer Str. 223-225, D-57076 Siegen >Tel. : +49 271 48950-13, Fax : +49 271 48950-50 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.4 (GNU/Linux) >Comment: For info see http://www.gnupg.org > >iD8DBQE7KcuPpm53PRScYygRAlfZAJ91r/8CwDzWpu0TU0vB+FRP18w14QCg4sCK >GBnoWm0xkKgHgFucJcNrsno= >=8hel >-----END PGP SIGNATURE----- > > > >

June 17, 2001

CS_PARENTDC problems

by Malte.Starostik＠t-online.de

Hi, we had some serious painting problems with dialog from an ActiveX control. All controls were invisible and only showed up sometimes on getting or losing focus. The cause is a custom class "_BitmapClass" that draws a logo and has the CS_PARENTDC class style (and no other class styles FWIW). Its WM_ERASEBKGND handler fills the complete dialog rect with that default Win95-Desktop-Background colour. According to the Win32 docs winelib behaves correctly wrt CS_PARENTDC and clipping. In this case it'd be Macromedia's fault as to how they implemented that window. However, I just found http://msdn.microsoft.com/library/techart/msdn_classy32.htm: <classy> If you use the CS_PARENTDC style for a class, each window in that class uses its parent window's DC. CS_PARENTDC is similar to CS_CLASSDC in that multiple windows share one DC. In CS_PARENTDC, however, the windows that share the DC need not belong to the same class. </classy> This contradicts the API docu at http://msdn.microsoft.com/library/psdk/winui/winclass_3b1v.htm: <api docs> CS_PARENTDC Sets the clipping rectangle of the child window to that of the parent window so that the child can draw on the parent. A window with the CS_PARENTDC style bit receives a regular device context from the system's cache of device contexts. It does not give the child the parent's device context or device context settings. Specifying CS_PARENTDC enhances an application's performance. <api docs> a little later, this is as near as the "classy" text comes to clipping: <classy> Another outcome of the CS_PARENTDC style is that child windows can draw anywhere in their parent's client area as well as drawing in their own client area. The CTL3D library, which creates 3-D effects around edit controls and list boxes, relies on this behavior. An application should not use CS_PARENTDC if it needs to adjust the mapping modes for different child windows. This will negate much of the benefit and could cause problems ensuring that each child window has the correct mapping mode set. </classy> Then I tried on Windows (2000), created a window with a child that has CS_PARENTDC set and * The paint rect of the PAINTSTRUCT as intialized by BeginPaint() equals the window's client rect - as expected. * but - surprise - so does the DC's clip box and trying to largen it to cover some or all areas of the parent fail and of course any drawing on the parent fails. * same for the DC returned by GetDC(hWnd) * only GetDCEx(hWnd, 0, DCX_PARENTCLIP) returns a DC that allows painting on the parent (no difference to a non-CS_PARENTDC window though) So, how is this painting on the parent with that style flag supposed to work? The things above make me think that it isn't possible at all or requires some additional steps. This would at least explain why the dialog described above looks busted in wine. If anyone could confirm my observations I'd come up with a patch. Thanks for any info, -Malte -- Wars don't determine who's right, only who's left.

June 17, 2001

Re: PATCH: wine-config

by Andreas Mohr

On Sun, Jun 17, 2001 at 10:26:34AM +0200, Marcus Meissner wrote: > Hi, > > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) > > Ciao, Marcus > > Changelog: > Added a 'wine-config' for winelib developers. I don't think this is a good idea. That way it'll get confused with wineconf within fractions of a second... I'd much rather use a name like wlib-config or winelib-config instead. -- Andreas Mohr

June 17, 2001

Re: wrc error

by Francois Gouget

On Fri, 15 Jun 2001, Gaël de Chalendar wrote: > Hi, > > As I wrote on comp.emulators.ms-windows.wine, I have the same problem (on 2 > machines, a third one works well). What caused the problem is the last patch > on wrc (I got the previous version of wrc files and it works). > > A preprocessed version of what do you want ? I wanted a preprocessed version of the user32.rc file. But Bang Jun-Young sent me the files generated by flex/bison which allowed me to reproduce the problem. I have not yet found a fix but the problem is in the y.tab.c file. Bang Jun-Young is using byacc while I'm using bison so the files are quite different and about impossible to compare. When I compile parser.y I get: bison -y -d -t ./parser.y conflicts: 2 shift/reduce Maybe that's the source of the problem: byacc resolves the conflicts differently from bison which causes tehe parse to fail. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

June 15, 2001

Re: SIGSEGV while trying to run Word97

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 15 June 2001 15:09, you wrote: > On Fri, 15 Jun 2001, Heiko Nardmann wrote: > > > Did you try current CVS? There has been a mmap fix which might help > > > those problems or is causing them ;) > > > > I tried this with the yesterday version of CVS wine (I am running CVS > > mirror and auto compilation via cron.daily). > > Maybe you should try again. AFAICT the fix for mmap was committed the > afternoon of 14th June, so maybe you got an earlier one. Of course, > there are other sig11's lurking, but this one (that is now fixed) is > late fallout not so easy to debug, so I think it best to get it out of > the way first. > I tried again with the version I updated today and really, I see no SIGSEGV any longer in the strace log files. On the other hand my success result is still the same - none. I still get the same dialog as stated in the previous mail. I am going to look deeper into the log files next time to see what causes this dialog. - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Kh+5pm53PRScYygRAkuDAKCpXge+VGY68DYe2eXpXxs3z5u3xACdEbyA uw+imdHcCw+ArOvcB8stbTo= =Cv9o -----END PGP SIGNATURE-----

June 15, 2001

Re: SIGSEGV while trying to run Word97

by lawson_whitney＠juno.com

On Fri, 15 Jun 2001, Heiko Nardmann wrote: > > > > Did you try current CVS? There has been a mmap fix which might help > > those problems or is causing them ;) > > > > I tried this with the yesterday version of CVS wine (I am running CVS mirror > and auto compilation via cron.daily). Maybe you should try again. AFAICT the fix for mmap was committed the afternoon of 14th June, so maybe you got an earlier one. Of course, there are other sig11's lurking, but this one (that is now fixed) is late fallout not so easy to debug, so I think it best to get it out of the way first. > > > If it is still there with current CVS, please tell us your glibc and kernel > > version :) > > > > uname -a gives: > Linux snsrv053 2.2.18 #3 Fri Mar 9 16:33:30 MET 2001 i686 unknown > > Additionally I should add that the kernel is patched with FreeSWan. > > Self compiled. > > System is SuSE 7.0. > > > rpm -qif /lib/libc.so.6 gives: > Name : shlibs Relocations: (not relocateable) > Version : 2.1.3 Vendor: SuSE GmbH, Nuernberg, ... > [.. rpm output about authors snipped ...] > > > Ciao, Marcus > Lawson ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

June 15, 2001

Re: SIGSEGV while trying to run Word97

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 15 June 2001 11:01, Marcus Meissner wrote: > On Fri, Jun 15, 2001 at 10:47:11AM +0200, Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder > > unzureichender Speicherplatz, um Word auszuführen" (German version). > > After trying to examine this problem with debugmsg all (without real > > success) I added an strace call to the whole call. This resulted in a log > > file which tells me that a SIGSEGV occurrs. Here is a part of the strace > > log file which contains the SIGSEGV message. After that the appropriate > > 'debugmsg all' part follows. What can be done to shed more light onto > > this problem? > > > > write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 > > - --- SIGSEGV (Speicherzugriffsfehler) --- > > Did you try current CVS? There has been a mmap fix which might help > those problems or is causing them ;) > I tried this with the yesterday version of CVS wine (I am running CVS mirror and auto compilation via cron.daily). > If it is still there with current CVS, please tell us your glibc and kernel > version :) > uname -a gives: Linux snsrv053 2.2.18 #3 Fri Mar 9 16:33:30 MET 2001 i686 unknown Additionally I should add that the kernel is patched with FreeSWan. Self compiled. System is SuSE 7.0. glibc is: /lib/libc.so.6 rpm -qif /lib/libc.so.6 gives: Name : shlibs Relocations: (not relocateable) Version : 2.1.3 Vendor: SuSE GmbH, Nuernberg, Germany Release : 141 Build Date: Son 30 Jul 2000 21:44:37 MEST Install date: Mon 22 Jan 2001 11:15:36 MET Build Host: Langmuir.suse.de Group : System Environment/Libraries Source RPM: libc-2.1.3-141.src.rpm Size : 24200680 License: LGPL Packager : feedback(a)suse.de Summary : The shared libraries (from the c-library-package) Description : Shared C libraries - needed to run programs linked with libc and libm libraries (almost all). Further basic support for international codepages and some binaries contained in the libc-source. [.. rpm output about authors snipped ...] > Ciao, Marcus - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KdpHpm53PRScYygRAlggAKCdswg9TRmKMfWxbeCnSuRQjhz3hACfeQsN JZahog733NLymzVguQyY2/Y= =MZ0O -----END PGP SIGNATURE-----

June 15, 2001

Re: SIGSEGV while trying to run Word97

by Marcus Meissner

On Fri, Jun 15, 2001 at 10:47:11AM +0200, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder > unzureichender Speicherplatz, um Word auszuführen" (German version). After > trying to examine this problem with debugmsg all (without real success) I > added an strace call to the whole call. This resulted in a log file which > tells me that a SIGSEGV occurrs. Here is a part of the strace log file which > contains the SIGSEGV message. After that the appropriate 'debugmsg all' part > follows. What can be done to shed more light onto this problem? > write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 > - --- SIGSEGV (Speicherzugriffsfehler) --- Did you try current CVS? There has been a mmap fix which might help those problems or is causing them ;) If it is still there with current CVS, please tell us your glibc and kernel version :) Ciao, Marcus

June 15, 2001

SIGSEGV while trying to run Word97

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder unzureichender Speicherplatz, um Word auszuführen" (German version). After trying to examine this problem with debugmsg all (without real success) I added an strace call to the whole call. This resulted in a log file which tells me that a SIGSEGV occurrs. Here is a part of the strace log file which contains the SIGSEGV message. After that the appropriate 'debugmsg all' part follows. What can be done to shed more light onto this problem? strace log: write(2, "08069280:trace:win32:_LeaveSysLe"..., 112) = 112 write(2, "08069280:Ret user32.CreateWindo"..., 68) = 68 write(2, "08069280:RET mso97.486: _MsoCre"..., 84) = 84 write(2, "08069280:trace:heap:HeapFree (40"..., 74) = 74 write(2, "08069280:Call kernel32.GetVersio"..., 49) = 49 write(2, "08069280:Ret kernel32.GetVersio"..., 65) = 65 write(2, "08069280:Call kernel32.GetVersio"..., 60) = 60 write(2, "08069280:Ret kernel32.GetVersio"..., 68) = 68 write(2, "08069280:Call kernel32.GlobalMem"..., 65) = 65 time(NULL) = 992531763 time(NULL) = 992531763 open("/proc/meminfo", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035c000 read(11, " total: used: free:"..., 1024) = 319 read(11, "", 1024) = 0 close(11) = 0 munmap(0x4035c000, 4096) = 0 write(2, "08069280:Ret kernel32.GlobalMem"..., 73) = 73 write(2, "08069280:CALL mso97.394: _MsoFCr"..., 147) = 147 write(2, ") ret=30011010\n", 15) = 15 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 mmap2(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) old_mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40e90000 munmap(0x40ea0000, 65536) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 write(2, "08069280:trace:virtual:VIRTUAL_S"..., 63) = 63 mprotect(0x40e90000, 4096, PROT_READ|PROT_WRITE) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e90fff c-rW-\n", 32) = 32 write(2, " 40e91000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:RET mso97.394: _MsoFCr"..., 126) = 126 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_RtlUnwind"..., 55) = 55 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_CallHandl"..., 54) = 54 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:trace:seh:EXC_RtlRaiseE"..., 63) = 63 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wine debug log: 08069280:trace:win32:_LeaveSysLevel (0x40753a74, level 2): thread 0x8069280 (fs 008f, pid 24063) count after 0 08069280:Ret user32.CreateWindowExW() retval=00000138 ret=306cc216 08069280:RET mso97.486: _MsoCreateMonitorWindow(a)0() retval = 00000000 ret=3000162f 08069280:trace:heap:HeapFree (40360000,00000002,403a4a80): returning TRUE 08069280:Call kernel32.GetVersion() ret=30001984 08069280:Ret kernel32.GetVersion() retval=05650004 ret=30001984 08069280:Call kernel32.GetVersionExA(405c686c) ret=300019b5 08069280:Ret kernel32.GetVersionExA() retval=00000001 ret=300019b5 08069280:Call kernel32.GlobalMemoryStatus(405c6900) ret=300019e2 08069280:Ret kernel32.GlobalMemoryStatus() retval=405c6900 ret=300019e2 08069280:CALL mso97.394: _MsoFCreateIPref(a)28(<unknown, check return>08069280:trace:heap:HeapAlloc (40360000,00000002,00000040): returning 403a4b98 ) ret=30011010 08069280:Call kernel32.VirtualAlloc(00000000,0000fffc,00002000,00000001) ret=3070b360 08069280:trace:virtual:VirtualAlloc 00000000 0000fffc 2000 00000001 View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b360 08069280:Call kernel32.VirtualAlloc(40e90000,00001000,00001000,00000004) ret=3070b38b 08069280:trace:virtual:VirtualAlloc 40e90000 00001000 1000 00000004 08069280:trace:virtual:VIRTUAL_SetProt 40e90000-40e90fff c-rW- View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e90fff c-rW- 40e91000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b38b 08069280:RET mso97.394: _MsoFCreateIPref(a)28(30011020,00000000,08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8aca,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8aca,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8baa,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8baa,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KcuPpm53PRScYygRAlfZAJ91r/8CwDzWpu0TU0vB+FRP18w14QCg4sCK GBnoWm0xkKgHgFucJcNrsno= =8hel -----END PGP SIGNATURE-----

June 15, 2001

Re: wrc error

by Gaël de Chalendar

Hi, As I wrote on comp.emulators.ms-windows.wine, I have the same problem (on 2 machines, a third one works well). What caused the problem is the last patch on wrc (I got the previous version of wrc files and it works). A preprocessed version of what do you want ? Bye Gael On Fri, 15 Jun 2001, Bang Jun-Young wrote: > Hi, > > I got the following error when I tried to compile the latest > CVS source: > > gmake[2]: Entering directory `/home/bjy/wine/dlls/user' > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc > resources/user32_Ca.rc:2:1: Error: syntax error > gmake[2]: *** [resources/user32.res] Error 1 I did a cvs update five minutes ago and it compiled just fine. cvs diff shows no difference in te tools/wrc area either. Can you send me a preprocessed version? -- -- _______________________________________________ Gael de Chalendar LIMSI/CNRS, BP 133, 91 403 Orsay Cedex (France) Tel : 01 69 85 80 04, Fax : 01 69 85 80 88 E-mail : mailto:Gael.de.Chalendar(a)limsi.fr Web : http://www.limsi.fr/Individu/gael/

June 15, 2001