From: Jacques M. <j-m...@ti...> - 2007-07-30 14:08:49
|
This is an old post I made last November Since then I have tried every incoming releases including the last available win32 sbcl-1.0.6-x86-windows I am not using SLIME I know that most people do not have the problem (including myself on my home PC) Apperently I am not the only one having this strange error People are talking on the web about some "patches" or experiments with "editbin" But, I have not yet found a satisfactory workaround Regards, Jacques >> Not on my home PC (XP family edition), but ONLY my latop (XP pro), >> since release 0.9.10, ALL win32 binary packages available are >> unable to give me the initial user prompt because of a >> "VirtualAlloc" error >> >> Moreover, re-compilation from their respective sources are falling >> at "make-target-2.sh" for the same reason >> >> ---------------------------------------------- >> >> So I am still using the old 0.9.9 binary distribution that works >> fine (and that I can recompile successfuly from its source) >> >> ---------------------------------------------- >> >> Searching what has changed after 0.9.9, I have noticed that SBCL >> was requesting a new DLL (SHELL32) for resolving the >> "SHGetFolderPath()" function >> >> So, I have commented out the 2 declarations in >> src/code/win32.lisp and src/runtime/win32-os.c of the 0.9.17 source >> to suppress this dependence to SHELL32 and the compilation >> completed successfuly producing a sbcl.exe without "VirtualAlloc" >> error (but complaining about "GetFolderPath") >> >> So, it sounds to me that THE suspect is my "SHELL32.dll" (XP pro, >> Version 2002, Service Pack 2) that somewhat conflict with the >> actual SBCL Virtual Memory mappping >> >> Regards, >> Jacques shell32.dll: file format pei-i386 Characteristics 0x210e executable line numbers stripped symbols stripped 32 bit words DLL Time/Date Thu Jul 13 15:33:24 2006 ImageBase 7c9c0000 SectionAlignment 00001000 FileAlignment 00000200 MajorOSystemVersion 5 MinorOSystemVersion 1 MajorImageVersion 5 MinorImageVersion 1 MajorSubsystemVersion 4 MinorSubsystemVersion 10 Win32Version 00000000 SizeOfImage 00815000 SizeOfHeaders 00000400 CheckSum 00816c54 Subsystem 00000002 (Windows GUI) DllCharacteristics 00000000 SizeOfStackReserve 00040000 SizeOfStackCommit 00001000 SizeOfHeapReserve 00100000 SizeOfHeapCommit 00001000 LoaderFlags 00000000 NumberOfRvaAndSizes 00000010 |
From: Jacques M. <j-m...@ti...> - 2007-08-02 07:10:36
|
This is an old post I made last November Since then I have tried every incoming releases including the last available win32 sbcl-1.0.6-x86-windows I am not using SLIME I know that most people do not have the problem (including myself on my home PC) Apperently I am not the only one having this strange error People are talking on the web about some "patches" or experiments with "editbin" But, I have not yet found a satisfactory workaround Regards, Jacques >> Not on my home PC (XP family edition), but ONLY my latop (XP pro), >> since release 0.9.10, ALL win32 binary packages available are >> unable to give me the initial user prompt because of a >> "VirtualAlloc" error >> >> Moreover, re-compilation from their respective sources are falling >> at "make-target-2.sh" for the same reason >> >> ---------------------------------------------- >> >> So I am still using the old 0.9.9 binary distribution that works >> fine (and that I can recompile successfuly from its source) >> >> ---------------------------------------------- >> >> Searching what has changed after 0.9.9, I have noticed that SBCL >> was requesting a new DLL (SHELL32) for resolving the >> "SHGetFolderPath()" function >> >> So, I have commented out the 2 declarations in >> src/code/win32.lisp and src/runtime/win32-os.c of the 0.9.17 source >> to suppress this dependence to SHELL32 and the compilation >> completed successfuly producing a sbcl.exe without "VirtualAlloc" >> error (but complaining about "GetFolderPath") >> >> So, it sounds to me that THE suspect is my "SHELL32.dll" (XP pro, >> Version 2002, Service Pack 2) that somewhat conflict with the >> actual SBCL Virtual Memory mappping >> >> Regards, >> Jacques shell32.dll: file format pei-i386 Characteristics 0x210e executable line numbers stripped symbols stripped 32 bit words DLL Time/Date Thu Jul 13 15:33:24 2006 ImageBase 7c9c0000 SectionAlignment 00001000 FileAlignment 00000200 MajorOSystemVersion 5 MinorOSystemVersion 1 MajorImageVersion 5 MinorImageVersion 1 MajorSubsystemVersion 4 MinorSubsystemVersion 10 Win32Version 00000000 SizeOfImage 00815000 SizeOfHeaders 00000400 CheckSum 00816c54 Subsystem 00000002 (Windows GUI) DllCharacteristics 00000000 SizeOfStackReserve 00040000 SizeOfStackCommit 00001000 SizeOfHeapReserve 00100000 SizeOfHeapCommit 00001000 LoaderFlags 00000000 NumberOfRvaAndSizes 00000010 |
From: Nikodemus S. <nik...@ra...> - 2007-08-02 07:42:38
|
On 8/2/07, Jacques Mequin <j-m...@ti...> wrote: > >> Not on my home PC (XP family edition), but ONLY my latop (XP pro), > >> since release 0.9.10, ALL win32 binary packages available are > >> unable to give me the initial user prompt because of a > >> "VirtualAlloc" error SBCL wants to map certain memory spaces in known addresses. Windows preloads the problematic DLL at one of those spaces, so the map fails. The fix will be to teach SBCL how to relocate those memory spaces. A tentative patch by David Lichteblau exists, that does just that. It's not merged yet, and there is no set schedule. Maybe a month, maybe a year. Cheers, -- Nikodemus |
From: Christophe R. <cs...@ca...> - 2007-08-02 07:51:20
|
Jacques Mequin <j-m...@ti...> writes: > People are talking on the web about some "patches" or experiments > with "editbin" > > But, I have not yet found a satisfactory workaround I can only suggest that instead of looking for workarounds, you learn enough about what the underlying problem is to be able to fix it. Good luck! Cheers, Christophe |