- Wine-Devel - list.winehq.org

segfault fault at startup
by terra＠gnome.org May 31, 2004

May 31, 2004

A newly built wine segfaults for me. No args: welinder(a)anemone:~/wine> ./wine Segmentation fault No core. gdb just reports: welinder(a)anemone:~/wine> LD_LIBRARY_PATH=/home/welinder/wine/libs/wine gdb loader/wine ... (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 28622)] [New Thread 32769 (LWP 28624)] [New Thread 16386 (LWP 28625)] Cannot find user-level thread for LWP 28622: generic error This is with a suse 9.0 system. Ideas? Morten

4 4

Re: segfault fault at startup
by terra＠gnome.org May 31, 2004

May 31, 2004

No change with 'set follow-fork-mode child', or even '... ask'. With strace, I get... strace -i $WINELOADER [...] [40113d71] close(9) = 0 [400f0c37] getpid() = 30133 [40113ce3] open("/tmp/reg75b50000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 [401140b8] fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) [40112dcb] fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 [4011e6ed] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40032000 [40121ce7] _llseek(9, 0, [0], SEEK_CUR) = 0 [400b7fdc] --- SIGSEGV (Segmentation fault) @ 0 (0) --- upeek: ptrace(PTRACE_PEEKUSER,30133,48,0): No such process [????????] +++ killed by SIGSEGV +++ Hmm... welinder(a)anemone:~/wine> printenv | grep WINE WINESERVER=/home/welinder/wine/server/wineserver WINELOADER=/home/welinder/wine/loader/wine WINEDLLPATH=/home/welinder/wine/dlls:/home/welinder/wine/programs:/home/welinder/wine/dlls:/home/welinder/wine/programs welinder(a)anemone:~/wine> gdb $WINELOADER GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... (gdb) tb main Breakpoint 1 at 0x8048857: file glibc.c, line 76. (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 30150)] [Switching to Thread 16384 (LWP 30150)] main (argc=1, argv=0xbffff414) at glibc.c:76 76 const char *loader = getenv( "WINELOADER" ); (gdb) info symbol 0x400b7fdc nl_langinfo + 60 in section .text (I'm not sure I believe that) Morten

1 0

Help with winedbg
by Shachar Shemesh May 30, 2004

May 30, 2004

Hi, I'm trying to get a Visual C compiled program to run on Wine. I have the sources and full debug info for the PE part of the program. Obviously, however, it was not compiled on the same machine on which it is running. To make things even more interesting, I would rather use some GUI frontend for the debugger. As far as I can tell, I have two options to go about this: 1. Use Visual Studio's remote debugging 2. Use winedbg as a gdb backend for ddd Option 1 fails miserably. I suspect the project is just too complex for Visual Studio to handle over the wire. When I try to do that, the Visual Studio front end (the one running on a Windows machine) crashes. This leaves me with just option 2. When I try to run it like that (winedbg --gdb --no-start), winedbg starts ok. When I hook ddd to it, however, winedbg complains about a missing source file (one that is not in the Windows source, btw). In the mean while, ddd claims to time out on the connection, and closes down. Am I missing something? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

2 7

Tainted code in User32?
by Steven Edwards May 30, 2004

May 30, 2004

Hello this line: "However, disassembling NT implementation (WIN32K.SYS) reveals that........." in http://source.winehq.org/source/windows/win.c#L845 was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Thanks Steven __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

4 3

Re: EnumDateFormats patch
by Alexandre Julliard May 29, 2004

May 29, 2004

Wililam <computerman413(a)ezrs.com> writes: > Here is the ChangeLog entry: > > * dlls/kernel/lcformat.c > William Lahti <computerman413(a)ezrs.com> > > - Implemented the EnumDateFormatsW function and vastly improved upon the > EnumDateFormatsA function. This stuff clearly needs to be stored as data in the nls resource files, not in the code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [Fwd: winetest: copy and submit manually]
by Dimitrie O. Paun May 29, 2004

May 29, 2004

On Fri, May 28, 2004 at 07:42:54AM -0400, Robert Reif wrote: > It appears that the locale.c test on line 1866 and 1867 fail a lot > (0xffff?). Can you try to see why this happens on your box? > File too big (# > 1 MB), copy and submit manually > > where # is around 8 meg. Yeah, there's no point in submitting such a large file, it will be rejected by the server. The message about submitting manually is confusing, it should be 'this is a problem, please report (and investigate, if at all possible :))' -- Dimi.

2 1

Re: Print thread ID in 16-bit snoop traces in the noargs case
by Rein Klazes May 29, 2004

May 29, 2004

On Fri May 28 23:42:14 BST 2004, you wrote: > Mike Hearn <mh(a)codeweavers.com> > Print thread ID in 16-bit snoop traces in the noargs case Too late: http://cvs.winehq.org/patch.py?id=12478 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Upcoming breakage warning
by Mike Hearn May 29, 2004

May 29, 2004

Hi, On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation. Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area. This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it. There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this: wine: unable to create process heap Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes. thanks -mike

4 5

Re: wine/ loader/main.c loader/glibc.c loader/Make ...
by Mike Hearn May 29, 2004

May 29, 2004

On Fri, 28 May 2004 15:59:23 -0500, Alexandre Julliard wrote: > Log message: > Initial version of the Wine preloader, used to reserve memory > areas at startup. Based on the work of Mike McCormack. For those who haven't been following the execshield/prelink saga, this commit is the result of the various prototypes and patches that were posted to wine-devel since we got back from WineConf. The result of it should be that we no longer need to switch off execshield nor prelink in order to run Wine reliably, also the huge BSS array hack is also no longer needed. Binaries of every size should work. Combined with the patch Alexandre checked in a few days ago to do an iterative binary search of the upper 2gig of address space, we should now also be functional when the 4G/4G VM split is enabled. It could use some testing! Please update to latest CVS and run wine as you would normally. If you are on a prelink/execshield enabled system, make sure they are both switched on and that prelink is using exec-shield mode (should be by default). If you observe any odd breakage please let us know. keep on truckin' -mike

3 3

Re: Fix CoMarshalInterThreadInterfaceInStream
by Mike Hearn May 29, 2004

May 29, 2004

( again wishing pan respected reply-to fields ... ) On Sat, 29 May 2004 00:33:24 +0100, Robert Shearman wrote: > This patch fixes CoMarshalInterThreadInterfaceInStream and > CoGetInterfaceAndReleaseStream to match what MSDN says - calling > CoMarshalInterface and CoUnmarshalInterface respectively. Without this > patch a particular InstallShield installer would just hang. With this > patch it gets a bit further (to an unimplemented function). Calling CoMarshalInterface in this case doesn't actually do much, but if it helps InstallShield OK. If you are interested in this stuff I'd say trying to merge the TransGaming patch would be a good start. This includes a lot of what you've done lately such as proper apartments, proper inter-thread marshalling and so on. Otherwise the codebase drift is going to get even worse :( thanks -mike

1 0