http://bugs.winehq.org/show_bug.cgi?id=2113
telefrancisco(a)lycos.es changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From telefrancisco(a)lycos.es 2004-18-06 14:37 -------
As of CVS of tday appears to run perfectly, so i leave this to resolved.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2292
------- Additional Comments From Oli1417(a)gmx.net 2004-18-06 14:29 -------
Created an attachment (id=615)
--> (http://bugs.winehq.org/attachment.cgi?id=615&action=view)
xst.debug.11.+loaddll+relay+file+ntdll+server.RelayExclude.with-comments.bz2
New trace of the problem with +relay, +file,+ntdll,+server and
"RelayExclude" =
"RtlEnterCriticalSection;RtlLeaveCriticalSection;RtlTryEnterCriticalSection;RtlDeleteCriticalSection;kernel32.InterlockedExchange;kernel32.GetCurrentThreadId;_EnterSysLevel;_LeaveSysLevel;LOCAL_Lock;LOCAL_Unlock;TlsGetValue;kernel32.GetLastError;kernel32.SetLastError;RtlAllocateHeap;RtlFreeHeap"
The trace contains *DEBUG MARK*s and comments. I think it in terms of a
trace it's pretty complete now and should allow a first diagnosis.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2298
------- Additional Comments From xavim(a)ubxlab.com 2004-18-06 13:27 -------
I have scanned dlls/kernel/process.c and the problem seems to be build_envp()
unconditionally "fixing" the child environment. I do not know, though, whether
modifying it would break a lot of things, and I am too ignorant to make a patch.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2298
------- Additional Comments From xavim(a)ubxlab.com 2004-18-06 13:18 -------
Created an attachment (id=614)
--> (http://bugs.winehq.org/attachment.cgi?id=614&action=view)
sources and exes that show this bug (parent.c, child.c)
I am attaching the sources included in the bug description, along with a
Makefile and the MinGW (under Win98SE) compiled binaries.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2298
Summary: wine messes up child process environment
Product: Wine
Version: 20040309
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: xavim(a)ubxlab.com
CC: xavim(a)ubxlab.com
When a process calls CreateProcessA (or its C runtime library wrapper _spawn*)
to invoke a child process with a newly generated environment, wine modifies this
environment before passing it to the child.
Namely, it adds entries for HOME, COMSPEC, PATH, TEMP, TMP, windir and winsysdir
variables.
This behaviour is incompatible with Windows, as the following example shows:
<code filename="parent.c">
#include <process.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
char *child_env[] = {
"entry_0",
"entry_1",
"entry_2",
NULL
};
char cmdname[] = "child.exe";
printf("Parent started.\n");
_spawnle(_P_WAIT, cmdname, cmdname, NULL, child_env);
return 0;
}
</code>
<code filename="child.c">
#include <stdio.h>
#include <stdlib.h>
static void print_env(char **env);
int
main(int argc, char *argv[])
{
printf("Child started.\n");
printf("In child: ");
print_env(_environ);
return 0;
}
static void
print_env(char **env)
{
printf("env = [ ");
if (env != NULL) {
while (*env != NULL) {
printf("%s, ", *env);
++env;
}
}
printf("]\n");
}
</code>
After compiling these two programs with MinGW under Win98SE, we get the
following output:
Running in Win98 (SE):
E:\...>parent.exe
Parent started.
Child started.
In child: env = [ entry_0, entry_1, entry_2, ]
E:\...>
Running wine under Debian (unstable):
$ wine parent.exe
Parent started.
Child started.
In child: env = [ HOME=/home/javi, entry_0, entry_1, entry_2,
COMSPEC=C:\WINDOWS\SYSTEM\wcmd.exe,
PATH=C:\syntech\bin;C:\Windows;C:\Windows\system;X:\;X:\test;Y:\, TEMP=C:\TMP,
TMP=C:\TMP, windir=C:\WINDOWS, winsysdir=C:\WINDOWS\SYSTEM, SYSTEMROOT=C:\WINDOWS, ]
Wine exited with a successful status
$
$ wine --version
Wine 20040309
Wine exited with a successful status
$ uname -a
Linux pandora 2.4.22 #1 Sat Oct 11 23:23:24 CEST 2003 i686 GNU/Linux
$
This incompatibility is giving some problems because of the following:
Due to the old DOS restriction about command line length (I think it was about
max. 127 bytes), some command line tools used to pass arguments using the
environment. When this tools were ported to Win32, this behaviour remained.
Because of this behaviour, when wine messes up the environment, the child
process complains about "Bad arguments" and exits.
I am having this problem with a Win32 Toshiba toolchain for a microcontroller.
The C compiler is actually a driver that invokes child process to perform the
different compilation phases, and they fail for the aforementioned reason.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
------------- Begin Forwarded Message -------------
X-Spam-Status: No, hits=-4.9 required=4.0
Date: Thu, 17 Jun 2004 21:16:47 -0500
From: Andrew Jones <aijones2(a)bsu.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rsparapa(a)mcw.edu
Subject: Wine bug #1816 (Wine on Solaris x86)
X-OriginalArrivalTime: 18 Jun 2004 02:16:50.0635 (UTC)
FILETIME=[50AD39B0:01C454DA]
I saw that you submitted this bug, thanks to google.
http://bugs.winehq.com/show_bug.cgi?id=1816
I ran into the same problem compiling wine 20040615, the newest release.
In server/context_i386.c, I just commented out everything that used
GETREGS or GETFPREGS since it's only for error reporting. I don't know
enough about win32 to say whether error reporting is important here.
In server/ptrace.c, I #define'd PT_ATTACH and PT_DETACH to -1, since
they're not supported by Solaris either. I don't know how well this
will work, but it's better than the alternative of disabling the use of
ptrace() entirely, making win32 threading nonfunctional.
------------- End Forwarded Message -------------
Rodney Sparapani Medical College of Wisconsin
Sr. Biostatistician Patient Care & Outcomes Research
rsparapa(a)mcw.edu http://www.mcw.edu/pcor
Was 'Name That Tune' rigged? WWLD -- What Would Lombardi Do
26,27c26
< #include <errno.h>
<
---
> #include <errno.h>
30,31c29
< #endif
<
---
> #endif
34d31
<
37,38c34
< #endif
<
---
> #endif
68,69c64
< #endif
<
---
> #endif
72,73c67
< #endif
<
---
> #endif
76,77c70
< #endif
<
---
> #endif
247,249c240,241
< struct regs regs;
< /* who needs error checking, right? */
< /*if (ptrace( PTRACE_GETREGS, pid, (int) ®s, 0 ) == -1) goto error;*/
---
> struct regs regs;
> if (ptrace( PTRACE_GETREGS, pid, (int) ®s, 0 ) == -1) goto error;
283,286c275,276
< /* correct structure (the same as fsave/frstor) */
<
< /* errors are for people less confident than I */
< /*if (ptrace( PTRACE_GETFPREGS, pid, (int) &context->FloatSave, 0 ) == -1) goto error;*/
---
> /* correct structure (the same as fsave/frstor) */
> if (ptrace( PTRACE_GETFPREGS, pid, (int) &context->FloatSave, 0 ) == -1) goto error;
304,307c294,295
< /* need to preserve some registers */
<
< /* what was that I said about errors?*/
< /*if (ptrace( PTRACE_GETREGS, pid, (int) ®s, 0 ) == -1) goto error;*/
---
> /* need to preserve some registers */
> if (ptrace( PTRACE_GETREGS, pid, (int) ®s, 0 ) == -1) goto error;
333,335c321,322
< }
< /* ptrace() is horrible, ugly, and doesn't work on solaris anyway */
< /*if (ptrace( PTRACE_SETREGS, pid, (int) ®s, 0 ) == -1) goto error;*/
---
> }
> if (ptrace( PTRACE_SETREGS, pid, (int) ®s, 0 ) == -1) goto error;
344,347c331,332
< /* correct structure (the same as fsave/frstor) */
<
< /* see above */
< /*if (ptrace( PTRACE_SETFPREGS, pid, (int) &context->FloatSave, 0 ) == -1) goto error;*/
---
> /* correct structure (the same as fsave/frstor) */
> if (ptrace( PTRACE_SETFPREGS, pid, (int) &context->FloatSave, 0 ) == -1) goto error;
59,81c59,67
< #ifndef SOLARIS
< #ifndef HAVE_SYS_PTRACE_H
< #define PT_CONTINUE 0
< #define PT_ATTACH 1
< #define PT_DETACH 2
< #define PT_READ_D 3
< #define PT_WRITE_D 4
< #define PT_STEP 5
< /*This is a load of bullshit right here. Solaris has no ptrace.h, but ptrace() works for those things. (maybe)
< inline static int ptrace(int req, ...) { errno = EPERM; return -1;} */
< #endif /* HAVE_SYS_PTRACE_H */
< #endif /* SOLARIS */
<
< #ifdef SOLARIS
< #define PT_CONTINUE 7
< /* attach and detach are not supported in Solaris. */
< #define PT_ATTACH -1
< #define PT_DETACH -1
< #define PT_READ_D 2
< #define PT_WRITE_D 5
< #define PT_STEP 9
< /* these are from ptrace(3C), I think they're the same as FreeBSD */
< #endif /* SOLARIS */
---
> #ifndef HAVE_SYS_PTRACE_H
> #define PT_CONTINUE 0
> #define PT_ATTACH 1
> #define PT_DETACH 2
> #define PT_READ_D 3
> #define PT_WRITE_D 4
> #define PT_STEP 5
> inline static int ptrace(int req, ...) { errno = EPERM; return -1; /*FAIL*/ }
> #endif /* HAVE_SYS_PTRACE_H */