http://bugs.winehq.org/show_bug.cgi?id=24101
Summary: [Urgent] CreateProcess failed (1359) with process tree. Product: Wine Version: 1.2 Platform: x86-64 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: critical Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: guillaume.ortega@OpenPlug.com
Hi,
I working on porting an IDE on MacOSX with the help of Wine, And I discover a random bug on wine.
Please use the sample code in attachement (BugProject visual studio project) to reproduce it (to be compiled on Windows)
On Mac with Wine I get this type of message (Log in attachement TestMacOSX10.6.4.log):
CreateProcess failed (1359).
On Windows everything work (Log in attachement WindowsXPSP3.log).
I used wine 1.2, 1.3.0 and 1.1.39 on MacOSX 10.6.4 SnowLeopard (Intel hardware) and Windows XP SP3.
Could you help me?
Best Regards,
Syphius.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #1 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-23 10:06:59 --- Created an attachment (id=30329) --> (http://bugs.winehq.org/attachment.cgi?id=30329) Bug Zip
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2010-08-23 10:32:40 --- That's essentially a fork bomb, you are most likely running out of file handles or some other resource. What are you trying to achieve with this?
http://bugs.winehq.org/show_bug.cgi?id=24101
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P3 CC| |dank@kegel.com Summary|[Urgent] CreateProcess |CreateProcess failed (1359) |failed (1359) with process |with process tree. |tree. | Severity|critical |normal
--- Comment #3 from Dan Kegel dank@kegel.com 2010-08-23 11:29:37 --- Not critical. See http://bugs.winehq.org/page.cgi?id=fields.html#importance
http://bugs.winehq.org/show_bug.cgi?id=24101
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|kernel32 |-unknown Summary|CreateProcess failed (1359) |Recursive CreateProcess() |with process tree. |fails
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #4 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-24 03:09:32 --- I'm trying to achieve nothing with this special example just to see you the bug.
I get same messages with my IDE, it run lot's of Mafile in cascade like 4, 5 level of process. And I get this type of messages :
process_begin: CreateProcess(C:\windows\temp\make131-2.bat, C:\windows\temp\make131-2.bat, ...) failed.
make (e=1359): Internal error
or
arm-elf-g++: CreateProcess: No such file or directory
I can reproduce it easily with the project I give to you.
Could you help me? Where should I patch Wine to this working?
Best Regards.
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-24 03:25:12 --- First you need to create a more reasonable test case which shows the problem.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-24 03:36:36 ---
From the test output it looks like Windows never reports a failure from
CreateProcess(), but CreateProcess() actually fails.
You may try to test the process/thread handles returned to see if they are valid handles.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2010-08-24 03:49:09 --- The first thing to try would be to increase your ulimit -n.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #8 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-24 04:09:13 --- Hi,
There is no problem on Windows, all my processes are created just see the log file number :
2^0 of Test_0 (1) 2^1 of Test_1 (2) 2^2 of Test_2 (4) 2^3 of Test_3 (8) 2^4 of Test_4 (16) 2^5 of Test_5 (32) 2^6 of Test_6 (64) 2^7 of Test_7 (128)
I tried to set 3000 in ulimit -n on mac, but the bug remains.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #9 from Dan Kegel dank@kegel.com 2010-08-24 07:13:55 --- Did you increase ulimit properly, though? It's kind of tricky:
sudo bash ulimit -n 10000 su $LOGNAME
(or maybe $USERNAME instead of $LOGNAME) That will give you a shell with a raised file descriptor limit.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #10 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-24 08:46:05 --- I tried your method, but same problem.
http://bugs.winehq.org/show_bug.cgi?id=24101
Guillaume ORTEGA guillaume.ortega@OpenPlug.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P3
--- Comment #11 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-25 11:08:11 --- Hello,
I did some test on the source code of wine.
The problem seems to be in server/process.c in process_poll_event
When the process doesn't work I received in the argument event 0x11 thus POLLUP and POLLIN.
And the process is killed in : if (event & (POLLERR | POLLHUP)) kill_process( process, 0 );
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #12 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-27 10:16:14 --- Hi,
I've some news about my investigation :
- the kill_process on the server is called before the child process begin (on the fork of create_process) - the child start and stop on server_init_thread(ntdll server.c) on wine_server_send_fd( reply_pipe[1] ); with sendmsg that return EPIPE.
If you have some idea, please let me know.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #13 from Dan Kegel dank@kegel.com 2010-08-27 10:22:20 --- Can you get the bug to happen with gnu make (with -j10 or something) or a similar build tool instead of your sample code?
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #14 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-30 09:14:22 CDT --- Created an attachment (id=30482) --> (http://bugs.winehq.org/attachment.cgi?id=30482) Same problems with gnu make
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #15 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-30 09:16:10 CDT --- Hi,
I get the same problem with gnu make(win32), just execute make -j10 -f testMake.make. I get this problem in my windows IDE, so it's not a fake problem.
Best Regards.
Guillaume.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #16 from Dan Kegel dank@kegel.com 2010-08-30 09:25:57 CDT --- That's not a very realistic use of make.
Your IDE should only be spawning roughly the same number of compile jobs as you have CPU cores available, maybe a few more. How many cores do you have, and how many compile jobs are you spawning?
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #17 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-30 09:46:07 CDT --- Hi,
It's a use of make to reproduce the problem nearly every times. When I'm compiling in my IDE I have 1 process that execute make + 2 cascaded makes + 3 cascaded process for executing gcc (My process, gcc and process that is launched by gcc), and make -j5, and with 2 cores.
The problems happens randomly, but when compiling big project I get an error in nearly every build.
If you modify my example for 4 or 5 cascaded makes you should have the problem sometimes.
My first example is realistic, I get the error on the 4th cascaded CreateProcess
Best Regards.
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #18 from Dan Kegel dank@kegel.com 2010-08-30 09:51:49 CDT --- It is an abuse of gnu make to pass -j5 to a nested make. You should only pass -j5 to the outer make. It kind of sounds like you don't know how many processes you're spawning; the number is probably unreasonably high.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #19 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-30 10:33:57 CDT --- Created an attachment (id=30486) --> (http://bugs.winehq.org/attachment.cgi?id=30486) Make from our product
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #20 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-30 10:35:52 CDT --- Sorry I it's not -j5 but -j3.
I know exactly how many process I spawn:
1 process that create make 1 parallel make at the first level (even with -j3 because of dependencies) 3 parallel makes at the second level 3 process at max level, because the exe OP_gen.exe execute gcc, and gcc execute ld, collect...
In the first release of the IDE I set -j1 to "resolve" the problem, but a users in MacOSX Snow Leopard gets that error even with -j1 everywhere.
I sent to you a 2 real make files of our IDE.
Best Regards,
Guillaume ORTEGA - Software engineer at OpenPlug (http://www.openplug.com)
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #21 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-31 10:51:30 CDT --- Hello,
I did some new investigations. I tested my project (Bug Zip) on Linux: - Kubuntu 10.04 - Wine 1.2 (auto installed with apt-get) - Dual Core cpu - With a call to ulimit -n 10000
And the test project work. It seems to be a problem with the MacOS Porting part.
My company try to port an IDE to MacOSX with the help of Wine. We only have problems when compiling a big project on MacOSX, the product use GNU make and arm-gcc to compile this project.
The building process create cascaded process : - 1 Process run Gnu Make - 1 Sub make is created with -j3 (problem also with -j1) - 3 Sub makes creates an OP_Gen.exe process that run gcc - 1 and gcc run also cc1, collect ect... - And make also create sub batch (.bat) scripts in all steps
I identify the problem, and it's related to create cascaded process, I create the project in attachement Bug Zip to Debug easyly.
I investigate with traces, I detect 2 part that cause the problems :
- process_poll_events (server/process.c) on the server is called with argument event at 11, before the child process begin (on the fork of create_process (dlls/kernel32/process.c))
- the child start at create_process (dlls/kernel32/process.c) and stop on server_init_thread(dlls/ntdll/server.c) on wine_server_send_fd( reply_pipe[1] );. And on wine_server_send_fd I get the EPIPE error with the sendmsg.
It seems the communication socket (create with socketpair) is closed somewhere else.
We are disposed to debug ourselves the bug and make a patch for the community.
Could someone could help us to investigate the problem? Where in the porting could be the problem?
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2010-08-31 11:01:06 CDT --- You should get a full trace of the system calls to determine whether it's a race in Wine or in the Mac OS kernel.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #23 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-08-31 11:08:17 CDT --- Hi,
Thank you for your answer.
How could I do that?
I try Wine with trace +all, and server debug at maximum.
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2010-08-31 11:54:34 CDT --- You need system-level tools like dtrace or ktrace.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-31 23:12:41 CDT --- Could you test your code under Linux? Does it expose the same problem?
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #26 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-09-01 02:57:32 CDT --- Hello Dmitry Timoshkov,
I already did some investigations on linux (Bug Zip): - Kubuntu 10.04 - Wine 1.2 (auto installed with apt-get) - Dual Core cpu - With a call to ulimit -n 10000
And the test project work, there is no problem on Linux. It seems to be a problem with the MacOS Porting part.
Best Regards,
Guillaume ORTEGA.
PS: I will test your tools Alexandre Julliard.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #27 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-09-02 11:27:08 CDT --- Hello,
I've some news about my investigation, I setup some DTrace scripts on my MacOSX. I trace all errocs on kernel function, I get on wineserver lots of error same as this :
wineserver recvmsg 35\n 1 18555 recvmsg:return libSystem.B.dylib`recvmsg$UNIX2003+0xa wineserver`process_poll_event+0x91 wineserver`fd_poll_event+0x1e wineserver`main_loop_epoll+0x396 wineserver`main_loop+0x31 wineserver`main+0x11c wineserver`start+0x35 wineserver`0x1
35 is the errno number, it correspond to EAGAIN or EWOULDBLOCK on MacOSX. Does this means something for you?
I send to you logs for the process wine, could you just check it to see if I didn't miss something?
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #28 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-09-02 11:28:08 CDT --- Created an attachment (id=30523) --> (http://bugs.winehq.org/attachment.cgi?id=30523) Wine error log
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #29 from Alexandre Julliard julliard@winehq.org 2010-09-02 12:11:36 CDT --- That's not a very useful log I'm afraid. What you want is a trace of the full sequence of system calls, with corresponding process id, not just the errors.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #30 from Dan Kegel dank@kegel.com 2010-09-02 12:18:31 CDT --- Also, EAGAIN / EWOULDBLOCK are not really errors per se.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #31 from Ken Thomases ken@codeweavers.com 2010-09-11 03:48:03 CDT --- Created an attachment (id=30697) --> (http://bugs.winehq.org/attachment.cgi?id=30697) Version of dtruss which tracks file descriptors
I was inspired by this bug to put together something I've been thinking about for a while. It's a dtrace-based script for tracking file descriptors.
It's built from the dtruss script that ships with Mac OS X. The important change is that I've added a -F option to focus the tracing on file descriptors. This limits the tracing to those syscalls which open/create or close fds. It also reports the affected fd in the output.
One useful way to invoke it is: sudo dtruss -lsF -n wine >&/tmp/foo.log
The -l includes PID & TID in output. I have modified this to include a call sequence number within a thread. That's useful because DTrace reports data out of order. (Each CPU core fills its own buffer. When it's full, it sends it to userland and starts another. So, the data from a given core is in order with respect to itself, but may be out of order with respect to other cores.)
The -s includes stack traces for each call.
The "-n wine" traces processes whose executable name starts with "wine".
The -F restricts tracing to syscalls related to file descriptors. That includes those that open or create them (open(), dup(), socketpair(), etc.), the close() call, setting or clearing close-on-exec with fcntl(), and calls which implicitly duplicate or close them (execve() for close-on-exec fds, fork(), exit(), etc.).
For this bug, I have also made -F report syscalls which encounter EBADF, EPIPE, EMFILE, and ENFILE.
Fds are printed as <pid>:<fd> (e.g. 6502:11) so that the same fd in different processes can be easily distinguished. If something interesting happens to a particular fd, you can search for that pattern to find what opened or closed it. However, you might not find it that easily. For example, if an fd was inherited by a child process from its parent, to find the creation point you'd have to find the fork() to identify the parent and then look for the fd with respect to that pid.
Harder still is when an fd is received via recvmsg. The script does trace the fds sent by sendmsg, but it is not necessarily straightforward to identify which sendmsg was responsible for a given recvmsg. One potential solution might be to add a timestamp to the tracing. Dtruss supports that to some extent (-d), but I'm not sure the timestamp it uses is coherent across processes, threads, and CPU cores. I saw some weird results. I tried to add the ability to use a different timestamp, but the resulting program exceeded DTrace's limits.
Anyway, I hope it helps.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #32 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-09-21 03:10:18 CDT --- Hi,
I finally found and fix the problem :
in dlls/kernel32/process.c function create_process:
if (socketpair( PF_UNIX, SOCK_STREAM, 0, socketfd ) == -1) { RtlReleasePebLock(); HeapFree( GetProcessHeap(), 0, winedebug ); HeapFree( GetProcessHeap(), 0, startup_info ); SetLastError( ERROR_TOO_MANY_OPEN_FILES ); return FALSE; } wine_server_send_fd( socketfd[1] ); close( socketfd[1] );
On MacOSX the function wine_server_send_fd is not blocking, so when close(socketfd[1] ); is executed sometimes the server hasn't received the fd.
So I just move the instruction close( socketfd[1] ); after the server request :
SERVER_START_REQ( new_process ) { req->inherit_all = inherit; req->create_flags = flags; req->socket_fd = socketfd[1]; req->exe_file = wine_server_obj_handle( hFile ); req->process_access = PROCESS_ALL_ACCESS; req->process_attr = (psa && (psa->nLength >= sizeof(*psa)) && psa->bInheritHandle) ? OBJ_INHERIT : 0; req->thread_access = THREAD_ALL_ACCESS; req->thread_attr = (tsa && (tsa->nLength >= sizeof(*tsa)) && tsa->bInheritHandle) ? OBJ_INHERIT : 0; req->info_size = startup_info_size;
wine_server_add_data( req, startup_info, startup_info_size ); wine_server_add_data( req, env, (env_end - env) * sizeof(WCHAR) ); if ((ret = !wine_server_call_err( req ))) { info->dwProcessId = (DWORD)reply->pid; info->dwThreadId = (DWORD)reply->tid; info->hProcess = wine_server_ptr_handle( reply->phandle ); info->hThread = wine_server_ptr_handle( reply->thandle ); } process_info = wine_server_ptr_handle( reply->info ); } SERVER_END_REQ; close( socketfd[1] );
And it works.
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #33 from Guillaume ORTEGA guillaume.ortega@OpenPlug.com 2010-09-21 03:10:47 CDT --- Hi,
I finally found and fix the problem :
in dlls/kernel32/process.c function create_process:
if (socketpair( PF_UNIX, SOCK_STREAM, 0, socketfd ) == -1) { RtlReleasePebLock(); HeapFree( GetProcessHeap(), 0, winedebug ); HeapFree( GetProcessHeap(), 0, startup_info ); SetLastError( ERROR_TOO_MANY_OPEN_FILES ); return FALSE; } wine_server_send_fd( socketfd[1] ); close( socketfd[1] );
On MacOSX the function wine_server_send_fd is not blocking, so when close(socketfd[1] ); is executed sometimes the server hasn't received the fd.
So I just move the instruction close( socketfd[1] ); after the server request :
SERVER_START_REQ( new_process ) { req->inherit_all = inherit; req->create_flags = flags; req->socket_fd = socketfd[1]; req->exe_file = wine_server_obj_handle( hFile ); req->process_access = PROCESS_ALL_ACCESS; req->process_attr = (psa && (psa->nLength >= sizeof(*psa)) && psa->bInheritHandle) ? OBJ_INHERIT : 0; req->thread_access = THREAD_ALL_ACCESS; req->thread_attr = (tsa && (tsa->nLength >= sizeof(*tsa)) && tsa->bInheritHandle) ? OBJ_INHERIT : 0; req->info_size = startup_info_size;
wine_server_add_data( req, startup_info, startup_info_size ); wine_server_add_data( req, env, (env_end - env) * sizeof(WCHAR) ); if ((ret = !wine_server_call_err( req ))) { info->dwProcessId = (DWORD)reply->pid; info->dwThreadId = (DWORD)reply->tid; info->hProcess = wine_server_ptr_handle( reply->phandle ); info->hThread = wine_server_ptr_handle( reply->thandle ); } process_info = wine_server_ptr_handle( reply->info ); } SERVER_END_REQ; close( socketfd[1] );
And it works.
Best Regards,
Guillaume ORTEGA.
http://bugs.winehq.org/show_bug.cgi?id=24101
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #34 from Wylda wylda@volny.cz 2010-09-21 03:17:29 CDT ---
Thanks. Patches should go to wine-patches@ (they are not picked up from bugzilla).
http://bugs.winehq.org/show_bug.cgi?id=24101
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #35 from Dan Kegel dank@kegel.com 2010-09-21 07:26:00 CDT --- Nice job. It looks rather like a textbook use-after-close bug? Patch sent, http://www.winehq.org/pipermail/wine-patches/2010-September/093517.html
http://bugs.winehq.org/show_bug.cgi?id=24101
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #36 from Ken Thomases ken@codeweavers.com 2010-09-22 10:05:17 CDT --- (In reply to comment #32)
On MacOSX the function wine_server_send_fd is not blocking, so when close(socketfd[1] ); is executed sometimes the server hasn't received the fd.
What do you mean that it's "not blocking"? How did you determine this?
If wine_server_send_fd() isn't operating as expected, that seems like a problem with possibly more serious and widespread ramifications. Moving the close() for this one case may not be solving the problem the right way.
Looking at the code, it certainly seems like the fd has been passed off to the kernel via the sendmsg() call before wine_server_send_fd() has returned. I suppose there could be a bug in the kernel such that the file object is not independent of the sending user process until it's been copied to the receiving process.
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #37 from Ken Thomases ken@codeweavers.com 2010-09-23 12:57:48 CDT --- (In reply to comment #36)
I suppose there could be a bug in the kernel such that the file object is not independent of the sending user process until it's been copied to the receiving process.
Another theory is that, since the fd is a socket, the close() is doing an implicit shutdown(SHUT_RDWR). So, the receiver is getting a file descriptor which is still open, nominally, but can't be used for reading or writing.
http://bugs.winehq.org/show_bug.cgi?id=24101
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.6 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=24101
--- Comment #38 from Austin English austinenglish@gmail.com 2013-11-13 16:48:40 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=24101
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #39 from Sebastian Lackner sebastian@fds-team.de --- I was asked to take a look at this bug report. The patch from comment 35 shouldn't make a difference, and if it does, it probably really means that a bug is hidden somewhere else in either Wine or kernel code.
I looked at the corresponding code in ntdll and the wineserver, and the only mistake I could spot was a missing close(...) in server/thread.c - nevertheless this should be unrelated to this bug report: http://source.winehq.org/patches/data/107688
If someone is still able to reproduce this problem, please provide more details and especially help testing, otherwise it doesn't make much sense to keep this bug report open.
https://bugs.winehq.org/show_bug.cgi?id=24101
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net, | |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=24101
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|NEW |RESOLVED
--- Comment #40 from Austin English austinenglish@gmail.com --- Over 2 years with no reply, marking abandoned.
https://bugs.winehq.org/show_bug.cgi?id=24101
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Status|RESOLVED |CLOSED
--- Comment #41 from André H. nerv@dawncrow.de --- closing abandoned
-
wine-bugs＠winehq.org