Re: clisp crashes on startup
On Jul 12 20:48, Daniel Colascione wrote: On 7/10/12 8:41 AM, Daniel Colascione wrote: On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. It turns out that clisp uses bit 31 of each pointer for its gc mark bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ Ouch. work, however, when compiled with -DWIDE. In this mode, clisp uses two words for each lisp value --- one for the pointer and one for the metadata. Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also works, and without bloating memory use, but that requires that no real virtual address be in the range [0xC000, 0xDFFF]. That can't be guaranteed. WOW64 provides the full 32 bit VM address space. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote: On Jul 12 20:48, Daniel Colascione wrote: On 7/10/12 8:41 AM, Daniel Colascione wrote: On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. It turns out that clisp uses bit 31 of each pointer for its gc mark bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ Ouch. work, however, when compiled with -DWIDE. In this mode, clisp uses two words for each lisp value --- one for the pointer and one for the metadata. Hmm, I do not really want to maintain lisp32.exe and lisp64.exe variants, but maybe upstream can be persuaded to make that distinction in the clisp.exe driver. It's only for huge data and bad rebase addresses. And for huge data a self-compiled clisp makes sense to me. Serious lisp users use better lisp compilers anyway which compile to native code. (sbcl, lispworks, allegro). clisp's main strength is fast startup and fast IO. Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also works, and without bloating memory use, but that requires that no real virtual address be in the range [0xC000, 0xDFFF]. That can't be guaranteed. WOW64 provides the full 32 bit VM address space. Maybe also a documentation issue for rebaseing. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Jul 13 07:52, Reini Urban wrote: On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote: On Jul 12 20:48, Daniel Colascione wrote: On 7/10/12 8:41 AM, Daniel Colascione wrote: On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. It turns out that clisp uses bit 31 of each pointer for its gc mark bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ Ouch. work, however, when compiled with -DWIDE. In this mode, clisp uses two words for each lisp value --- one for the pointer and one for the metadata. Hmm, I do not really want to maintain lisp32.exe and lisp64.exe variants, but maybe upstream can be persuaded to make that distinction in the clisp.exe driver. It's only for huge data and bad rebase addresses. And for huge data a self-compiled clisp makes sense to me. Serious lisp users use better lisp compilers anyway which compile to native code. (sbcl, lispworks, allegro). clisp's main strength is fast startup and fast IO. Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also works, and without bloating memory use, but that requires that no real virtual address be in the range [0xC000, 0xDFFF]. That can't be guaranteed. WOW64 provides the full 32 bit VM address space. Maybe also a documentation issue for rebaseing. That has nothing to do with rebasing. If you build clisp with a recent gcc, it will have the bigaddr flag set in the file header since Cygwin's gcc sets that by default. While DLLs should be rebased from 0x7000 downwards as usual, the applications heap, as well as thread stacks, as well as shared memory regions created with mmap(2) or shmat(2) will be in the high memory area starting at 0x8000. THe bottom line is, if the distro clisp isn't 32 bit clean, which it apparently isn't using default settings, it should either be rebuilt with -DWIDE, or it should have the bigaddr flag removed from the file header by default (peflags -l0). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Fri, Jul 13, 2012 at 9:26 AM, Corinna Vinschen wrote: On Jul 13 07:52, Reini Urban wrote: On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote: On Jul 12 20:48, Daniel Colascione wrote: On 7/10/12 8:41 AM, Daniel Colascione wrote: On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. It turns out that clisp uses bit 31 of each pointer for its gc mark bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ Ouch. work, however, when compiled with -DWIDE. In this mode, clisp uses two words for each lisp value --- one for the pointer and one for the metadata. Hmm, I do not really want to maintain lisp32.exe and lisp64.exe variants, but maybe upstream can be persuaded to make that distinction in the clisp.exe driver. It's only for huge data and bad rebase addresses. And for huge data a self-compiled clisp makes sense to me. Serious lisp users use better lisp compilers anyway which compile to native code. (sbcl, lispworks, allegro). clisp's main strength is fast startup and fast IO. Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also works, and without bloating memory use, but that requires that no real virtual address be in the range [0xC000, 0xDFFF]. That can't be guaranteed. WOW64 provides the full 32 bit VM address space. Maybe also a documentation issue for rebaseing. That has nothing to do with rebasing. If you build clisp with a recent gcc, it will have the bigaddr flag set in the file header since Cygwin's gcc sets that by default. While DLLs should be rebased from 0x7000 downwards as usual, the applications heap, as well as thread stacks, as well as shared memory regions created with mmap(2) or shmat(2) will be in the high memory area starting at 0x8000. THe bottom line is, if the distro clisp isn't 32 bit clean, which it apparently isn't using default settings, it should either be rebuilt with -DWIDE, or it should have the bigaddr flag removed from the file header by default (peflags -l0). Thanks. This deserves an update now. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/13/12 9:30 AM, Reini Urban wrote:
On Fri, Jul 13, 2012 at 9:26 AM, Corinna Vinschen wrote:
On Jul 13 07:52, Reini Urban wrote:
On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote:
On Jul 12 20:48, Daniel Colascione wrote:
On 7/10/12 8:41 AM, Daniel Colascione wrote:
On 7/10/12 1:13 AM, Corinna Vinschen wrote:
On Jul 9 21:59, Daniel Colascione wrote:
On 7/9/12 2:26 PM, Daniel Colascione wrote:
[snip]
It turns out that clisp crashes only when I've rebased DLLs into the
high portion of the 4GB WOW64 address space.
Where did you rebase them to? You know that on WOW64 and with the
bigaddr flag on, the application heap is located at 0x8000 by
default, right? Perhaps some of your DLLs just collide with that?
I'm using a starting base address of 0xC800; I haven't had
problems with any other program.
It turns out that clisp uses bit 31 of each pointer for its gc mark
bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_
Ouch.
work, however, when compiled with -DWIDE. In this mode, clisp uses two
words for each lisp value --- one for the pointer and one for the
metadata.
Hmm, I do not really want to maintain lisp32.exe and lisp64.exe
variants, but maybe
upstream can be persuaded to make that distinction in the clisp.exe driver.
It's only for huge data and bad rebase addresses.
And for huge data a self-compiled clisp makes sense to me.
Serious lisp users use better lisp compilers anyway which compile
to native code. (sbcl, lispworks, allegro).
clisp's main strength is fast startup and fast IO.
Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also
works, and without bloating memory use, but that requires that no real
virtual address be in the range [0xC000, 0xDFFF].
That can't be guaranteed. WOW64 provides the full 32 bit VM address
space.
Maybe also a documentation issue for rebaseing.
That has nothing to do with rebasing. If you build clisp with a recent
gcc, it will have the bigaddr flag set in the file header since
Cygwin's gcc sets that by default. While DLLs should be rebased from
0x7000 downwards as usual, the applications heap, as well as
thread stacks, as well as shared memory regions created with mmap(2)
or shmat(2) will be in the high memory area starting at 0x8000.
THe bottom line is, if the distro clisp isn't 32 bit clean, which it
apparently isn't using default settings, it should either be rebuilt
with -DWIDE, or it should have the bigaddr flag removed from the
file header by default (peflags -l0).
Thanks. This deserves an update now.
Indeed. One caveat is that WIDE seems to be incompatible with clisp
threading. It'd probably be a good idea to send an email upstream and
ask the clisp people whether there's anything they can do. You'll also
need the attached patch, which fixes some macro-name conflicts that
arise when compiling with WIDE.
I'd code up something like LINUX_NOEXEC_HEAPCODES myself, but I'm
nervous about making those changes: lots of places in the code (like
the bytecode interpreter?!) look at LINUX_NOEXEC_HEAPCODES and do
subtly different things if it'd set. In principle, I don't see why we
should have to reserve [0xC000, 0xDFFF]: the bits that force
us out of this range could come from the low bits of the pointer
instead, and the cost would just be a coarser alignment requirement.
I'm happier with requiring coarser alignment than I am with carving
out a portion of the address space.
diff -r b689a1c1565e modules/syscalls/calls.c
--- a/modules/syscalls/calls.c Wed Jun 27 11:08:08 2012 -0400
+++ b/modules/syscalls/calls.c Fri Jul 13 09:42:45 2012 -0800
@@ -4550,7 +4550,7 @@
}
} else { /* Probably system just do not support UNICODE */
#endif
- gltext = GetClipboardData(CF_TEXT); /* ANSI TEXT */
+ HGLOBAL gltext = GetClipboardData(CF_TEXT); /* ANSI TEXT */
if (gltext != NULL) {
const char * str = (const char *)GlobalLock(gltext);
if (str != NULL) {
diff -r b689a1c1565e src/lispbibl.d
--- a/src/lispbibl.dWed Jun 27 11:08:08 2012 -0400
+++ b/src/lispbibl.dFri Jul 13 09:42:45 2012 -0800
@@ -13704,7 +13704,7 @@
const chart* charptr: pointer to the characters
(may be in string, may be on the stack) */
#ifdef HAVE_SMALL_SSTRING
- #define unpack_sstring_alloca_help_(string,len,offset,charptr_assignment,u) \
+ #define
unpack_sstring_alloca_help_(string,len,offset,charptr_assignment,ign) \
if (simple_nilarray_p(string)) {
\
if ((len) 0) error_nilarray_retrieve(); \
charptr_assignment NULL;
\
@@ -13718,12 +13718,12 @@
else if (sstring_eltype(TheSstring(string)) == Sstringtype_8Bit) \
copy_8bit_32bit(TheS8string(string)-data[offset],(cint32*)_unpacked_,len);\
else
\
- u;
Re: clisp crashes on startup
On 7/10/12 8:41 AM, Daniel Colascione wrote: On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. It turns out that clisp uses bit 31 of each pointer for its gc mark bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ work, however, when compiled with -DWIDE. In this mode, clisp uses two words for each lisp value --- one for the pointer and one for the metadata. Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also works, and without bloating memory use, but that requires that no real virtual address be in the range [0xC000, 0xDFFF]. signature.asc Description: OpenPGP digital signature
Re: clisp crashes on startup
On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/10/12 1:13 AM, Corinna Vinschen wrote: On Jul 9 21:59, Daniel Colascione wrote: On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. Where did you rebase them to? You know that on WOW64 and with the bigaddr flag on, the application heap is located at 0x8000 by default, right? Perhaps some of your DLLs just collide with that? I'm using a starting base address of 0xC800; I haven't had problems with any other program. signature.asc Description: OpenPGP digital signature
Re: clisp crashes on startup
On Sat, Jul 7, 2012 at 2:07 PM, Daniel Colascione wrote: On 7/7/2012 10:44 AM, marco atzeri wrote: On 7/7/2012 6:19 PM, Reini Urban wrote: On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe should be better. ldd does not advise about missing dll's $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe C:\lib\clisp-2.48\base\lisp.exe C:\bin\cyggcc_s-1.dll C:\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\bin\cygcrypt-0.dll C:\bin\cygiconv-2.dll C:\bin\cygintl-8.dll C:\bin\cygncurses-9.dll C:\bin\cygreadline7.dll C:\bin\cygncursesw-10.dll C:\Windows\system32\USER32.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\LPK.dll C:\Windows\system32\USP10.dll C:\Windows\system32\msvcrt.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\ADVAPI32.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\SspiCli.dll C:\Windows\system32\CRYPTBASE.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll C:\bin\cygsigsegv-2.dll C:\Windows\system32\OLE32.dll C:\Windows\system32\OLEAUT32.DLL ldd doesn't report an error either. ldd's output _is_ a bit odd, however: $ ldd /usr/lib/clisp-2.48/full/lisp.exe ntdll.dll = /Windows/SysWOW64/ntdll.dll (0x7de7) kernel32.dll = /Windows/syswow64/kernel32.dll (0x7dd6) KERNELBASE.dll = /Windows/syswow64/KERNELBASE.dll (0x7d85) cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0xc5ab) cygwin1.dll = /usr/bin/cygwin1.dll (0x6100) cygcrypt-0.dll = /usr/bin/cygcrypt-0.dll (0xc640) cygdb-4.5.dll = /usr/bin/cygdb-4.5.dll (0xc5fd) cygfcgi-0.dll = /usr/bin/cygfcgi-0.dll (0xc5e9) cyggdbm-4.dll = /usr/bin/cyggdbm-4.dll (0xc59e) cygiconv-2.dll = /usr/bin/cygiconv-2.dll (0xc411) cygintl-8.dll = /usr/bin/cygintl-8.dll (0xc40b) cygncurses-9.dll = /usr/bin/cygncurses-9.dll (0xc39e) cygpcre-0.dll = /usr/bin/cygpcre-0.dll (0xc37f) cygpq.dll = /usr/bin/cygpq.dll (0xc305) cygcrypto-0.9.8.dll = /usr/bin/cygcrypto-0.9.8.dll (0xc62c) cygz.dll = /usr/bin/cygz.dll (0xc21f) cygldap-2-3-0.dll = /usr/bin/cygldap-2-3-0.dll (0xc3e8) cyglber-2-3-0.dll = /usr/bin/cyglber-2-3-0.dll (0xc3f0) cygcrypto-1.0.0.dll = /usr/bin/cygcrypto-1.0.0.dll (0xc613) cygsasl2-2.dll =
Re: clisp crashes on startup
On 7/9/12 2:01 PM, Reini Urban wrote: On Sat, Jul 7, 2012 at 2:07 PM, Daniel Colascione wrote: On 7/7/2012 10:44 AM, marco atzeri wrote: On 7/7/2012 6:19 PM, Reini Urban wrote: On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe should be better. ldd does not advise about missing dll's $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe C:\lib\clisp-2.48\base\lisp.exe C:\bin\cyggcc_s-1.dll C:\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\bin\cygcrypt-0.dll C:\bin\cygiconv-2.dll C:\bin\cygintl-8.dll C:\bin\cygncurses-9.dll C:\bin\cygreadline7.dll C:\bin\cygncursesw-10.dll C:\Windows\system32\USER32.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\LPK.dll C:\Windows\system32\USP10.dll C:\Windows\system32\msvcrt.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\ADVAPI32.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\SspiCli.dll C:\Windows\system32\CRYPTBASE.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll C:\bin\cygsigsegv-2.dll C:\Windows\system32\OLE32.dll C:\Windows\system32\OLEAUT32.DLL ldd doesn't report an error either. ldd's output _is_ a bit odd, however: $ ldd /usr/lib/clisp-2.48/full/lisp.exe ntdll.dll = /Windows/SysWOW64/ntdll.dll (0x7de7) kernel32.dll = /Windows/syswow64/kernel32.dll (0x7dd6) KERNELBASE.dll = /Windows/syswow64/KERNELBASE.dll (0x7d85) cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0xc5ab) cygwin1.dll = /usr/bin/cygwin1.dll (0x6100) cygcrypt-0.dll = /usr/bin/cygcrypt-0.dll (0xc640) cygdb-4.5.dll = /usr/bin/cygdb-4.5.dll (0xc5fd) cygfcgi-0.dll = /usr/bin/cygfcgi-0.dll (0xc5e9) cyggdbm-4.dll = /usr/bin/cyggdbm-4.dll (0xc59e) cygiconv-2.dll = /usr/bin/cygiconv-2.dll (0xc411) cygintl-8.dll = /usr/bin/cygintl-8.dll (0xc40b) cygncurses-9.dll = /usr/bin/cygncurses-9.dll (0xc39e) cygpcre-0.dll = /usr/bin/cygpcre-0.dll (0xc37f) cygpq.dll = /usr/bin/cygpq.dll (0xc305) cygcrypto-0.9.8.dll = /usr/bin/cygcrypto-0.9.8.dll (0xc62c) cygz.dll = /usr/bin/cygz.dll (0xc21f) cygldap-2-3-0.dll = /usr/bin/cygldap-2-3-0.dll (0xc3e8) cyglber-2-3-0.dll = /usr/bin/cyglber-2-3-0.dll (0xc3f0) cygcrypto-1.0.0.dll = /usr/bin/cygcrypto-1.0.0.dll (0xc613)
Re: clisp crashes on startup
On 7/9/12 2:26 PM, Daniel Colascione wrote: [snip] It turns out that clisp crashes only when I've rebased DLLs into the high portion of the 4GB WOW64 address space. It looks like clisp isn't 32-bit clean. Turning off bigaddr on lisp.exe lets clisp load, but of course it can't fork. signature.asc Description: OpenPGP digital signature
Re: clisp crashes on startup
Greetings, Daniel Colascione! $ cat /etc/fstab none /drvcygdrive binary 0 0 c:/bin/usr/binntfs cygexec0 0 c:/bin/binntfs cygexec0 0 c:/usr/local/bin /usr/local/bin ntfs cygexec0 0 I'd suggest removing default mounts from fstab. Just in case, and not relevant to any observed issues. $ cat /etc/fstab.d/dancol c:/users/dancol/appdata/local/temp /tmp ntfs posix=0 0 0 $ mount C:/users/dancol/appdata/local/temp on /tmp type ntfs (binary,posix=0,user) C:/usr/local/bin on /usr/local/bin type ntfs (binary,cygexec) C:/bin on /usr/bin type ntfs (binary,cygexec) C:/bin on /bin type ntfs (binary,cygexec) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) -- WBR, Andrey Repin (anrdae...@freemail.ru) 09.07.2012, 03:13 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Trimming a bit ? Welcome to GNU CLISP 2.48 (2009-07-28) http://clisp.cons.org/ Type :h and hit Enter for context help. Segmentation fault (core dumped) no issue on W7/64 $ cat lisp.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=00421614 eax=8002 ebx=002965B3 ecx=805034FD edx=002965B0 esi=801DB65D edi=005C651C ebp=01335B18 esp=01335B10 program=C:\lib\clisp-2.48\base\lisp.exe, pid 4092, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 01335B18 00421614 (01335D5C, 01335D68, , 0001) 01335D78 0042C0C1 (004FE2A2, 10020028, 01336148, 004C1F7D) 01335D88 0042DAEC (00487E4C, 00020002, , 0002) 01336148 004C1F7D (0042DAD8, 8023650D, 01336198, 0046527B) 01336198 00425E7A (80056A34, 0007, 80229E5D, 002B002B) 01336268 00426D9B (0015, 8005A0F0, 013363D8, 610256D9) 013362A8 004767FA (0002, 642F7372, 6F636E61, 002E2F6C) 013363D8 00491599 (802346D9, 802C679B, 00503501, 0001) 013364E8 0049589B (00507981, 0001, 801FB682, 0047E704) 01336588 004823A8 (800568E0, 01336764, 800D11B2, 0047E704) 01336628 004846B3 (800CF45D, 0003, 800D1076, 0047E704) 013366C8 0048277A (01E8, 0004, 01336744, 80051BF4) 01336768 004846B3 (800D1045, 0003, 80051C44, 80051C90) 013368E8 0048277A (FFDA0074, 004FEFE0, 0001, 0133696C) 01336988 004846B3 (00504F41, 0003, 005C66D0, 005034E1) 01336BD8 0042F32B (6127B418, 80229E5D, 4000, 005034E1) End of stack trace (more stack frames may be present) your mount table looks strange C:/ system binary,auto c:\bin/binsystem text,cygexec c:/bin/usr/binsystem text,cygexec C:\lib/usr/libsystem binary,auto c:\usr\local\bin /usr/local/bin system text,cygexec cygdrive prefix /drvsystem binary,auto It is not recommended to use c:\ as root. Why half are mounted as text instead of binary ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Trimming a bit ? Not at all. I just installed the stock clisp package and tried to run it. your mount table looks strange C:/ system binary,auto c:\bin/binsystem text,cygexec c:/bin/usr/binsystem text,cygexec C:\lib/usr/libsystem binary,auto c:\usr\local\bin /usr/local/bin system text,cygexec cygdrive prefix /drvsystem binary,auto It is not recommended to use c:\ as root. I know. I'm doing it anyway. Using c:\ as root makes Windows and Cygwin paths very similar. I don't think the difference is material here. Why half are mounted as text instead of binary ? I think that's a cygcheck bug. $ cat /proc/mounts C:/users/dancol/appdata/local/temp /tmp ntfs binary,posix=0,user 1 1 C:/usr/local/bin /usr/local/bin ntfs binary,cygexec 1 1 C:/bin /usr/bin ntfs binary,cygexec 1 1 C:/bin /bin ntfs binary,cygexec 1 1 C:/lib /usr/lib ntfs binary,auto 1 1 C: / ntfs binary,auto 1 1 signature.asc Description: OpenPGP digital signature
Re: clisp crashes on startup
On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. clisp.exe is just a driver, which exec's base/lisp.exe or full/lisp.exe -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
Greetings, Daniel Colascione! $ clisp Trimming a bit ? Not at all. I just installed the stock clisp package and tried to run it. It was a suggestion, not a question. your mount table looks strange C:/ system binary,auto c:\bin/binsystem text,cygexec c:/bin/usr/binsystem text,cygexec C:\lib/usr/libsystem binary,auto c:\usr\local\bin /usr/local/bin system text,cygexec cygdrive prefix /drvsystem binary,auto It is not recommended to use c:\ as root. I know. I'm doing it anyway. Using c:\ as root makes Windows and Cygwin paths very similar. I don't think the difference is material here. Why half are mounted as text instead of binary ? I think that's a cygcheck bug. $ cat /proc/mounts C:/users/dancol/appdata/local/temp /tmp ntfs binary,posix=0,user 1 1 C:/usr/local/bin /usr/local/bin ntfs binary,cygexec 1 1 C:/bin /usr/bin ntfs binary,cygexec 1 1 C:/bin /bin ntfs binary,cygexec 1 1 C:/lib /usr/lib ntfs binary,auto 1 1 C: / ntfs binary,auto 1 1 What about `mount` output and contents of your /etc/fstab ? -- WBR, Andrey Repin (anrdae...@freemail.ru) 07.07.2012, 20:47 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/7/2012 6:19 PM, Reini Urban wrote: On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe should be better. ldd does not advise about missing dll's clisp.exe is just a driver, which exec's base/lisp.exe or full/lisp.exe Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On 7/7/2012 9:51 AM, Andrey Repin wrote: your mount table looks strange C:/ system binary,auto c:\bin/binsystem text,cygexec c:/bin/usr/binsystem text,cygexec C:\lib/usr/libsystem binary,auto c:\usr\local\bin /usr/local/bin system text,cygexec cygdrive prefix /drvsystem binary,auto Why half are mounted as text instead of binary ? I think that's a cygcheck bug. $ cat /proc/mounts C:/users/dancol/appdata/local/temp /tmp ntfs binary,posix=0,user 1 1 C:/usr/local/bin /usr/local/bin ntfs binary,cygexec 1 1 C:/bin /usr/bin ntfs binary,cygexec 1 1 C:/bin /bin ntfs binary,cygexec 1 1 C:/lib /usr/lib ntfs binary,auto 1 1 C: / ntfs binary,auto 1 1 What about `mount` output and contents of your /etc/fstab ? $ cat /etc/fstab none /drvcygdrive binary 0 0 c:/bin/usr/binntfs cygexec0 0 c:/bin/binntfs cygexec0 0 c:/usr/local/bin /usr/local/bin ntfs cygexec0 0 $ cat /etc/fstab.d/dancol c:/users/dancol/appdata/local/temp /tmp ntfs posix=0 0 0 $ mount C:/users/dancol/appdata/local/temp on /tmp type ntfs (binary,posix=0,user) C:/usr/local/bin on /usr/local/bin type ntfs (binary,cygexec) C:/bin on /usr/bin type ntfs (binary,cygexec) C:/bin on /bin type ntfs (binary,cygexec) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) signature.asc Description: OpenPGP digital signature
Re: clisp crashes on startup
On 7/7/2012 10:44 AM, marco atzeri wrote: On 7/7/2012 6:19 PM, Reini Urban wrote: On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: On 7/7/12 6:04 AM, marco atzeri wrote: On 7/7/2012 12:45 AM, Daniel Colascione wrote: $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe should be better. ldd does not advise about missing dll's $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe C:\lib\clisp-2.48\base\lisp.exe C:\bin\cyggcc_s-1.dll C:\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\bin\cygcrypt-0.dll C:\bin\cygiconv-2.dll C:\bin\cygintl-8.dll C:\bin\cygncurses-9.dll C:\bin\cygreadline7.dll C:\bin\cygncursesw-10.dll C:\Windows\system32\USER32.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\LPK.dll C:\Windows\system32\USP10.dll C:\Windows\system32\msvcrt.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\ADVAPI32.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\SspiCli.dll C:\Windows\system32\CRYPTBASE.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll C:\bin\cygsigsegv-2.dll C:\Windows\system32\OLE32.dll C:\Windows\system32\OLEAUT32.DLL ldd doesn't report an error either. ldd's output _is_ a bit odd, however: $ ldd /usr/lib/clisp-2.48/full/lisp.exe ntdll.dll = /Windows/SysWOW64/ntdll.dll (0x7de7) kernel32.dll = /Windows/syswow64/kernel32.dll (0x7dd6) KERNELBASE.dll = /Windows/syswow64/KERNELBASE.dll (0x7d85) cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0xc5ab) cygwin1.dll = /usr/bin/cygwin1.dll (0x6100) cygcrypt-0.dll = /usr/bin/cygcrypt-0.dll (0xc640) cygdb-4.5.dll = /usr/bin/cygdb-4.5.dll (0xc5fd) cygfcgi-0.dll = /usr/bin/cygfcgi-0.dll (0xc5e9) cyggdbm-4.dll = /usr/bin/cyggdbm-4.dll (0xc59e) cygiconv-2.dll = /usr/bin/cygiconv-2.dll (0xc411) cygintl-8.dll = /usr/bin/cygintl-8.dll (0xc40b) cygncurses-9.dll = /usr/bin/cygncurses-9.dll (0xc39e) cygpcre-0.dll = /usr/bin/cygpcre-0.dll (0xc37f) cygpq.dll = /usr/bin/cygpq.dll (0xc305) cygcrypto-0.9.8.dll = /usr/bin/cygcrypto-0.9.8.dll (0xc62c) cygz.dll = /usr/bin/cygz.dll (0xc21f) cygldap-2-3-0.dll = /usr/bin/cygldap-2-3-0.dll (0xc3e8) cyglber-2-3-0.dll = /usr/bin/cyglber-2-3-0.dll (0xc3f0) cygcrypto-1.0.0.dll = /usr/bin/cygcrypto-1.0.0.dll (0xc613) cygsasl2-2.dll = /usr/bin/cygsasl2-2.dll (0xc2e9) cygssl-1.0.0.dll = /usr/bin/cygssl-1.0.0.dll (0xc2bd) cygssl-0.9.8.dll = /usr/bin/cygssl-0.9.8.dll
