<html>Hello Gary, <br><br>Thanks for responding. It does seem that I got a backtrace for the wrong thread.<br>In any case, yes it does look as if I should look for the answer within Wine.<br>Thank you. I'm sorry to be a distraction.<br><br>--David <br><br>
<blockquote style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"><font face="Tahoma" size="2">-----Original Message-----<br><b>From:</b> Gary Byers [mailto:gb@clozure.com]<br><b>Sent:</b> Tuesday, July 23, 2013 11:06 AM<br><b>To:</b> dto@blocky.io<br><b>Cc:</b> openmcl-devel@clozure.com<br><b>Subject:</b> Re: SleepEx never returns<br><br></font>This looks like a backtrace of the initial thread; it indeed ordinarily
spends most of its time asleep (though I doubt if the alleged arguments
to SleepEx() in frame 3 have anything to do with how SleepEx() is actually
called.)
Are you looking at this thread because:
a) you have some reason to think that this has something to do with the reason
that you're hanging
or
b) because this was the easiest thread to get a backtrace for
?
I have no idea what the problem actually is. To be honest, I'm not that
interested unless there's some reason to think that it's a CCL bug. If
CCL was calling SleepEx with a large timeout value and a 0 "alertable"
argument that would indeed be a bug in almost all cases that I can imagine;
when I take a few seconds to grep through the sources, I can find no cases
where it does so.
On Tue, 23 Jul 2013, dto@blocky.io wrote:
> Hi Gary,
>
> So I rebuilt Wine after commenting out one line.
> But I may have run up against a wall.
> wx86cl.exe runs, and I get to a working REPL.
> But when trying do load ASDF or anything else,
> ccl calls SleepEx and just waits (see line 3 of the backtrace below.)
> After talking to a Wine developer, it looks like CCL is expecting to
> be woken up sooner than that.
>
> Is it possible to configure this behavior from within the CCL process?
>
> Probably though it's something Wine doesn't account for;
> but as the issue with the incorrect image-base was resolved with a one-line
> change, I suspect that a relatively simple solution is possible here.
>
> Backtrace:
> =>0 0x680011b0 in ld-linux.so.2 (+0x11b0) (0x0042fa18)
> 1 0x7bc80243 NTDLL_wait_for_multiple_objects+0x232(count=0, handles=(nil), flags=0x6, timeout=0x42fcc8, signal_object=<is not="" available="">) [/home/dto/src/wine/dlls/ntdll/sync.c:1123] in ntdll (0x0042fc38)
> 2 0x7bc8077e NtDelayExecution+0x19d(alertable=-88, timeout=(nil)) [/home/dto/src/wine/dlls/ntdll/sync.c:1209] in ntdll (0x0042fc98)
> 3 0x7b8723cf SleepEx+0x3e(timeout=0x42fba8, alertable=0) [/home/dto/src/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0042fcd8)
> 4 0x0001a13d _SPffcall+0x54() [/usr/local/src/ccl-1.9/lisp-kernel/win32/../x86-spentry32.s:4326] in 2x0ng (0x0042fd08)
> 5 0x0001a7ab _start_lisp+0x57() [/usr/local/src/ccl-1.9/lisp-kernel/win32/../x86-subprims32.s:119] in 2x0ng (0x0042fd28)
> 6 0x0001c68b main+0x40c(argc=0x42fba8, argv=(nil)) [/usr/local/src/ccl-1.9/lisp-kernel/win32/../pmcl-kernel.c:2125] in 2x0ng (0x0042fd88)
> 7 0x00011402 __tmainCRTStartup+0x281() [/usr/src/debug/mingw64-i686-runtime-3.0b_svn5452-1/crt/crtexe.c:315] in 2x0ng (0x0042fe60)
> 8 0x7b85f20c call_process_entry+0xb() in kernel32 (0x0042fe78)
> 9 0x7b86048b start_process+0x6a(peb=0x42fba8) [/home/dto/src/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0042feb8)
> 10 0x7bc78b40 call_thread_func_wrapper+0xb() in ntdll (0x0042fed8)
> 11 0x7bc7bb4d call_thread_func+0x7c(entry=0x7b860420, arg=0x7ffdf000, frame=0x42ffc8) [/home/dto/src/wine/dlls/ntdll/signal_i386.c:2567] in ntdll (0x0042ffa8)
> 12 0x7bc78b1e call_thread_entry_point+0x11() in ntdll (0x0042ffc8)
> 13 0x7bc4e0be start_process+0x1d(kernel_start=0x7b860420) [/home/dto/src/wine/dlls/ntdll/loader.c:2694] in ntdll (0x0042ffe8)
> 14 0x6802b7cd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
> 15 0x6802b88b wine_switch_to_stack+0x2a(func=0x7bc4e0a0, arg=0x7b860420, stack=0x430000) [/home/dto/src/wine/libs/wine/port.c:59] in libwine.so.1 (0xbfe984a8)
> 16 0x7bc53f60 LdrInitializeThunk+0x3af(kernel_start=0x42fba8, unknown2=0, unknown3=0x102, unknown4=0) [/home/dto/src/wine/dlls/ntdll/loader.c:2750] in ntdll (0xbfe98518)
> 17 0x7b8669e2 __wine_kernel_init+0xa21() [/home/dto/src/wine/dlls/kernel32/process.c:1256] in kernel32 (0xbfe996c8)
> 18 0x7bc5471b __wine_process_init+0x25a() [/home/dto/src/wine/dlls/ntdll/loader.c:2959] in ntdll (0xbfe99758)
> 19 0x68028d3c wine_init+0x28b(argc=0x2, argv=0xbfe99ca4, error="", error_size=0x400) [/home/dto/src/wine/libs/wine/loader.c:847] in libwine.so.1 (0xbfe997b8)
> 20 0x7bf00cfb main+0x8a(argc=<is not="" available="">, argv=<is not="" available="">) [/home/dto/src/wine/loader/main.c:237] in <wine-loader> (0xbfe99c08)
> 21 0x6820b4d3 __libc_start_main+0xf2(main=0x7bf00c70, argc=0x2, ubp_av=0xbfe99ca4, init=0x7bf01050, fini=0x7bf010c0, rtld_fini=0x6800f280, stack_end=0xbfe99c9c) [/build/buildd/eglibc-2.15/csu/libc-start.c:226] in libc.so.6 (0x00000000)
>
>
> -----Original Message-----
> From: Gary Byers [mailto:gb@clozure.com]
> Sent: Monday, July 22, 2013 12:35 PM
> To: dto@blocky.io
> Cc: openmcl-devel@clozure.com
> Subject: Re: [Openmcl-devel] question about "linker tricks" and "VirtualProtect spjump" error under Wine
>
> The linker tricks in question are: - passing the --image-base 0x10000 argument to ld.exe in ccl/lisp-kernel/win64/Makefile - telling ld.exe to use a linker script ("pei-x86-64.x") - in that linker script, reserving another 64K bytes between the (page-aligned) end of the executable file's headers and the start of its acual code,The intent is that the memory between #x11000 and #x21000 is mapped(readonly) and otherwise unused. We can achieve this effect in otherways on other platforms. remap_spjump() tries to write-enable a pagein this memory region (IIRC, at #x14000) so that something else canbe copied to that fixed address, and that fails under WINE. I'd guessthat the failure is caused by WINE's failure to have mapped the executableat the specifed image-base address in the first place, but that's justa guess.On Mon, 22 Jul 2013, dto@blocky.io wrote:> Greetings, Clozure CL community.> > I have a question about the "linker tricks" described near remap_spjump() in> the CCL so!
urce:> ??> ? ?http://svn.clozure.com/publicsvn/openmcl/trunk/source/lisp-kernel/pmcl-kern> el.c> > When attempting to run the Windows version of CCL under Wine 1.6, the> following error message results:> ?> ??? VirtualProtect spjump: 0x57 Invalid parameter.> > A Wine developer took a look at the source in question, and said that it> appeared that a VM feature that CCL is> using for memory reservation, isn't supported by Wine. He also said that if> I could get a clarification from CCL developers> on what the "linker tricks" are, I might be able to modify Wine so that it> works, without modifying CCL at all.> > Why am I doing this? I used to use SBCL.EXE with Wine in order to build> Windows EXE's of my games without> having Windows. But unfortunately, the resulting EXE won't work on some> 64-bit versions of Windows due to> an existing incompatibility in SBCL. I use CCL for the Windows versions now,> but I have to use a separate Windows> machine that I don't always have access!
to.> > For the curious, my current GPL game is here: http://b!
locky.io/2x0ng.html> And I'd like to thank you for helping me a few times on the IRC channel,> when I first started building> the game with CCL.> > So, I hope that with a little information, I could work with Wine developers> to make things compatible.> I would greatly appreciate any information you could offer as to what> remap_spjump() is doing.> > Thank you.> > --David> > > >
>
>
></wine-loader></is></is></is></blockquote></html>