Re: Fork issue on W10 WOW
Am 15.07.2018 um 08:49 schrieb Marco Atzeri: Am 14.07.2018 um 21:03 schrieb Brian Inglis: On 2018-07-14 11:58, Achim Gratz wrote: Marco Atzeri writes: it seems the WOW64*.dll can be anywhere between 5000-7F00 The 32 applications present at boot are: HP Cool Sense HP Audio Switch HP Jump Start HP Message Service Microsoft OneDrive Lavasof Webcompanion Wordweb Dictionary and also Lavasoft seems innocent as after removal 5C90-5C901000 5EE7-5EE71000 I will wait until 1803 is installed, download is in progress, before making new trials/experiments after 1803 the range seems more same 7773-77731000 77B1-77B11000 76ED-76ED1000 7720-77201000 before 1803 I removed AVG and Lavasoft and for the time being Avast AV is not giving me real problems after excluding the cygwin directories Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: Fork issue on W10 WOW
Am 15.07.2018 um 19:23 schrieb David Stacey: On 15/07/18 07:49, Marco Atzeri wrote: In this case AVG is innocent. I removed all AV and the lottery is still there The 32 applications present at boot are: Lavasof Webcompanion We've had trouble with that one in the past [1]. Dave. [1] - https://cygwin.com/ml/cygwin-patches/2015-q3/msg00022.html May be but removing is not improving the issue. And I see nothing strange in the register as residual setting of this and AVG Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: Fork issue on W10 WOW
Greetings, Marco Atzeri! > Lavasof Webcompanion -- With best regards, Andrey Repin Sunday, July 15, 2018 20:22:46 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: Fork issue on W10 WOW
On 15/07/18 07:49, Marco Atzeri wrote: In this case AVG is innocent. I removed all AV and the lottery is still there The 32 applications present at boot are: Lavasof Webcompanion We've had trouble with that one in the past [1]. Dave. [1] - https://cygwin.com/ml/cygwin-patches/2015-q3/msg00022.html -- 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: Fork issue on W10 WOW
Marco Atzeri writes: > In this case AVG is innocent. > I removed all AV and the lottery is still there Again, if the ASLR setup has been changed via registry, I wouldn't bet that the uninstallation of the application that changed them to reset to the defaults (if it was indeed AVG,). > it seems the WOW64*.dll can be anywhere between > 5000-7F00 Any ASLR aware library can be mapped to rather low adresses, but that usually means it couldn't load to where it originally wanted to go. MS actually uses this to force non-ASLR aware images to random addresses if the corresponding option is set. https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ > I will wait until 1803 is installed, download is in progress, > before making new trials/experiments If mandatory ASLR and bottom-up forced randomization got switched on, that will probably result in the same behaviour. 1803 should offer (most of) these options from some GUI tab (Security Center / App Control / Exploit Protection), I don't remember what 1709 had available there. The defaults are all "on" except forced ASLR, I think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Fork issue on W10 WOW
Am 14.07.2018 um 21:03 schrieb Brian Inglis: On 2018-07-14 11:58, Achim Gratz wrote: Marco Atzeri writes: Anyway, the only time I've seen similar behaviour was when some other library was occupying the address space the systems libraries should have occupied, and the they get some extremely random address assigned until the next reboot. To do this the other library must however be loaded pretty early in the boot process. If you wrote the mail on said laptop, this Diese E-Mail wurde von AVG auf Viren geprüft. might be an explanation for the whole thing. AVG is well known for intercepting things already during boot and loading a bunch of their libraries early. Some of it is still done even if you switch it off completely and some changes to the registry might even survive a deinstallation. +1 for AVG BLODA - had to deinstall that years ago, and was slow; only reason I still run an AV is to catch stuff, either in Windows binaries from download sources about which little info is publicly available, or in email which folks I trust forward once in a blue moon, from their greedy or gullible infected friends, who are in the main, clueless or in denial about it. In this case AVG is innocent. I removed all AV and the lottery is still there 63DF-63DF1000 74F4-74F41000 5DE2-5DE21000 it seems the WOW64*.dll can be anywhere between 5000-7F00 The 32 applications present at boot are: HP Cool Sense HP Audio Switch HP Jump Start HP Message Service Microsoft OneDrive Lavasof Webcompanion Wordweb Dictionary and also Lavasoft seems innocent as after removal 5C90-5C901000 5EE7-5EE71000 I will wait until 1803 is installed, download is in progress, before making new trials/experiments 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: Fork issue on W10 WOW
On 2018-07-14 11:58, Achim Gratz wrote: > Marco Atzeri writes: > Anyway, the only time I've seen similar behaviour was when some other > library was occupying the address space the systems libraries should > have occupied, and the they get some extremely random address assigned > until the next reboot. To do this the other library must however be > loaded pretty early in the boot process. If you wrote the mail on said > laptop, this >> Diese E-Mail wurde von AVG auf Viren geprüft. > might be an explanation for the whole thing. AVG is well known for > intercepting things already during boot and loading a bunch of their > libraries early. Some of it is still done even if you switch it off > completely and some changes to the registry might even survive a > deinstallation. +1 for AVG BLODA - had to deinstall that years ago, and was slow; only reason I still run an AV is to catch stuff, either in Windows binaries from download sources about which little info is publicly available, or in email which folks I trust forward once in a blue moon, from their greedy or gullible infected friends, who are in the main, clueless or in denial about it. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: Fork issue on W10 WOW
Marco Atzeri writes: > Nothing fancy, just vanilla fresh new > W10 64bit Home preinstalled on HP Notebook > German Language > Version 1709 > Build system 16299.547 Hmmm. That should update itself to 1803 almost the same second you let it anywhere near a network. Anyway, the only time I've seen similar behaviour was when some other library was occupying the address space the systems libraries should have occupied, and the they get some extremely random address assigned until the next reboot. To do this the other library must however be loaded pretty early in the boot process. If you wrote the mail on said laptop, this > Diese E-Mail wurde von AVG auf Viren geprüft. might be an explanation for the whole thing. AVG is well known for intercepting things already during boot and loading a bunch of their libraries early. Some of it is still done even if you switch it off completely and some changes to the registry might even survive a deinstallation. It sounds like you've already spent way more time with that problem than you thought you would, but my suggestion is to try a clean boot of a stock Windows installation. You can install one into a VHD and (multi-)boot into it without affecting your existing installation beyond the space taken up by the VHD file (german magazine c't has described both a manual way of doing that and developed a script that prepares the VHD so that it just needs to complete the installation when first booted). If that works OK without your current problems, you can then decide whether to keep a separate boot environment, trying to fix your existing install or wiping the pre-installed Windows and doing a fresh install on bare iron. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Fork issue on W10 WOW
Am 14.07.2018 um 16:50 schrieb Achim Gratz: Marco Atzeri writes: currently I have over 7300 always busy 73C5-73C51000 /cygdrive/c/Windows/SysWOW64/cryptbase.dll What type of Windows do you use? I have Home N for testing at home and Server 2016 plus a bunch of users w/ Enterprise clients (will get one myself in a few days) and never seen any such problems. .. Are you using one of the preview update channels or did you use one in the past? Leading up to 1803 MS has apparently tested some new ASLR tricks and I don't think they change the settings back to default even when you are later switching back to a "normal" release version. Anyway, with 1803 there is a setting now in the security panel somewhere that forces ASLR to be used even when the PE flags say otherwise. I don't know if that can be switched on just for the WoW64 subsystem, but it would probably be something you can do via group policy (on a Pro or Enterprise client). Nothing fancy, just vanilla fresh new W10 64bit Home preinstalled on HP Notebook German Language Version 1709 Build system 16299.547 Regards, Achim. Regards Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
Marco Atzeri writes: > currently I have over 7300 always busy > 73C5-73C51000 /cygdrive/c/Windows/SysWOW64/cryptbase.dll What type of Windows do you use? I have Home N for testing at home and Server 2016 plus a bunch of users w/ Enterprise clients (will get one myself in a few days) and never seen any such problems. >> You could reboot the machine until the DLLs are at an adddress you >> can work with and then never reboot again. /duck/ > > Feasible, just time consuming.. > It took a dozen trials before reaching a nice > > 71D1-71D11000 /cygdrive/c/Windows/System32/wow64.dll > > the last lottery numbers were: > > 5A9B-5A9B1000 > 66AB-66AB1000 > 53DA-53DA1000 > 6A47-6A471000 > 6DBF-6DBF1000 > 5F02-5F021000 > 680D-680D1000 > 5265-52651000 > 71D1-71D11000 > > Now I am stuck to German system and never > restart. Until next MS patch day... Are you using one of the preview update channels or did you use one in the past? Leading up to 1803 MS has apparently tested some new ASLR tricks and I don't think they change the settings back to default even when you are later switching back to a "normal" release version. Anyway, with 1803 there is a setting now in the security panel somewhere that forces ASLR to be used even when the PE flags say otherwise. I don't know if that can be switched on just for the WoW64 subsystem, but it would probably be something you can do via group policy (on a Pro or Enterprise client). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Fork issue on W10 WOW
Am 12.07.2018 um 15:38 schrieb Corinna Vinschen: On Jul 12 12:31, marco atzeri wrote: from my experiments the 32bit under W10 is substantially unusable. At every restart the base address of the wow64*.dll are moved randomly everywhere between 0x5000 and 0x7000. Actually, as I wrote before, in my case the wow64 stuff is beyond 0x7000: 76E9-76F08000 /mnt/c/Windows/System32/wow64win.dll 76F1-76F62000 /mnt/c/Windows/System32/wow64.dll 76F7-76F7A000 /mnt/c/Windows/System32/wow64cpu.dll something very nice on your system :-) currently I have over 7300 always busy 73C5-73C51000 /cygdrive/c/Windows/SysWOW64/cryptbase.dll You could reboot the machine until the DLLs are at an adddress you can work with and then never reboot again. /duck/ Feasible, just time consuming.. It took a dozen trials before reaching a nice 71D1-71D11000 /cygdrive/c/Windows/System32/wow64.dll the last lottery numbers were: 5A9B-5A9B1000 66AB-66AB1000 53DA-53DA1000 6A47-6A471000 6DBF-6DBF1000 5F02-5F021000 680D-680D1000 5265-52651000 71D1-71D11000 Now I am stuck to German system and never restart. Until next MS patch day... Corinna Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
On Jul 12 12:31, marco atzeri wrote: > On Tue, Jul 10, 2018 at 7:33 AM, Marco Atzeri wrote: > > Am 09.07.2018 um 14:37 schrieb Corinna Vinschen: > > > > > > It seems there is some type of ASLR for the wow64. > > I will try to rebase using 0x6b00 to see if > > make any change > > > > from my experiments the 32bit under W10 is substantially unusable. > At every restart the base address of the wow64*.dll are moved > randomly everywhere between 0x5000 and 0x7000. Actually, as I wrote before, in my case the wow64 stuff is beyond 0x7000: 76E9-76F08000 /mnt/c/Windows/System32/wow64win.dll 76F1-76F62000 /mnt/c/Windows/System32/wow64.dll 76F7-76F7A000 /mnt/c/Windows/System32/wow64cpu.dll > It seems the 32bit subsystem is totally ignoring that cygwin programs > have not the ASLR flag. May be the subsystem base address > is initialized before any cygwin program is started. The ASLRed addresses of system DLLs are puzzled out at system boottime, afaik. > It seems I have only two choices: > - disable totally ASLR, but some guidance (1) around seem not working anymore That won't work. You can't disable ASLR for system DLLs. > - use a virtual machine for a 32 bit W7 system to be used as build > environment. You could reboot the machine until the DLLs are at an adddress you can work with and then never reboot again. /duck/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Fork issue on W10 WOW
On Tue, Jul 10, 2018 at 7:33 AM, Marco Atzeri wrote: > Am 09.07.2018 um 14:37 schrieb Corinna Vinschen: > > > It seems there is some type of ASLR for the wow64. > I will try to rebase using 0x6b00 to see if > make any change > from my experiments the 32bit under W10 is substantially unusable. At every restart the base address of the wow64*.dll are moved randomly everywhere between 0x5000 and 0x7000. It seems the 32bit subsystem is totally ignoring that cygwin programs have not the ASLR flag. May be the subsystem base address is initialized before any cygwin program is started. It seems I have only two choices: - disable totally ASLR, but some guidance (1) around seem not working anymore - use a virtual machine for a 32 bit W7 system to be used as build environment. Any suggestion for the two approaches ? Regards Marco 1) https://gist.github.com/trietptm/b84ccad9db01f459ac7e -- 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: Fork issue on W10 WOW
Am 09.07.2018 um 14:37 schrieb Corinna Vinschen: It is like they put the 64bit System 32 over 0x6b00 (maybe) 0x6b00? In your previous mail you wrote 0x6f00. I used 0x6f00 for my last rebase experiment as wow64 was loading over there consistently. Anyway I found another craziness: Before I was using the system language default as DE, in that case the wow64 was loaded over 0x6f00. When I changed to system language default US and rebooted the wow64 was loaded over 0x7000. I am back again to system language default DE and now the wow64 is loaded at 51CD. The system 32 is still over 0x7000 It seems there is some type of ALSR for the wow64. I will try to rebase using 0x6b00 to see if make any change Regards Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
On Jul 9 13:37, Marco Atzeri wrote: > Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen: > > On Jul 8 18:03, Marco Atzeri wrote: > > > Am 30.06.2018 um 22:47 schrieb Ken Brown: > > > > On 6/30/2018 11:52 AM, Marco Atzeri wrote: > > > > > > > > I've never had this problem with my own 32bit installation on W10, but I > > > > just reproduced it by doing a new installation with your list of > > > > packages. Have you tried just installing a minimal list of packages > > > > that you need for building the packages you maintain? > > > > > > > > > > On a fresh minimal installation the problem can arise again > > > > > > $ cygcheck -cd |wc -l > > > 245 > > > > > > as the first system shared libs are lower than the rebase > > > DefaultBaseAddress=0x07000 > > > > > > 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll > > > 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll > > > > > > I think that rebase should consider different rebase > > > base address for W10. > > > > > > Using DefaultBaseAddress=0x06F00 seems fine > > > for the time being > > > > I can do that in the rebaseall script (I have a matching patch locally), > > but it looks like a race we can't win in the long run. 240 Megs less > > space is a lot given the number of DLLs in the distro. > > I know, but until we try to support the 32bit version, we need a > way to handle it. > > > To make matters worse, I just checked my local 32 bit W10 and it turns > > out that various Windows DLLs loaded by default (even in a simple tcsh) > > are at even lower addresses, e.g. > > > >6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll > > I suspect it is due the their 64bit base address netapi32.dll is 32 bit. And it's a 32 bit OS, not WOW64... > $ objdump -x /cygdrive/c/Windows/System32/wow64.dll|grep ImageBase > ImageBase 6b00 > > $ objdump -x /cygdrive/c/Windows/System32/wow64win.dll |grep ImageBase > ImageBase 6b18 > > It is like they put the 64bit System 32 over 0x6b00 (maybe) 0x6b00? In your previous mail you wrote 0x6f00. > and the WoW64 over 0x7000 I don't think there's a rule. On my 64 bit W10 system: 76E6-76ED8000 /mnt/c/Windows/System32/wow64win.dll 76EE-76EEA000 /mnt/c/Windows/System32/wow64cpu.dll 76EF-76F42000 /mnt/c/Windows/System32/wow64.dll Of course you can rebase the wow64 DLLs, it's just unclear if that helps, given Windows uses different DLL addresses for their system DLLs after each reboot. > But I guess that ALSR can play around that numbers. > There is still a way to disable ALSR? ASLR is disabled by default on Cygwin executables. Unless it can't be disabled anymore for certain (system?) DLLs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Fork issue on W10 WOW
Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen: On Jul 8 18:03, Marco Atzeri wrote: Am 30.06.2018 um 22:47 schrieb Ken Brown: On 6/30/2018 11:52 AM, Marco Atzeri wrote: I've never had this problem with my own 32bit installation on W10, but I just reproduced it by doing a new installation with your list of packages. Have you tried just installing a minimal list of packages that you need for building the packages you maintain? On a fresh minimal installation the problem can arise again $ cygcheck -cd |wc -l 245 as the first system shared libs are lower than the rebase DefaultBaseAddress=0x07000 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll I think that rebase should consider different rebase base address for W10. Using DefaultBaseAddress=0x06F00 seems fine for the time being I can do that in the rebaseall script (I have a matching patch locally), but it looks like a race we can't win in the long run. 240 Megs less space is a lot given the number of DLLs in the distro. I know, but until we try to support the 32bit version, we need a way to handle it. To make matters worse, I just checked my local 32 bit W10 and it turns out that various Windows DLLs loaded by default (even in a simple tcsh) are at even lower addresses, e.g. 6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll I suspect it is due the their 64bit base address $ objdump -x /cygdrive/c/Windows/System32/wow64.dll|grep ImageBase ImageBase 6b00 $ objdump -x /cygdrive/c/Windows/System32/wow64win.dll |grep ImageBase ImageBase 6b18 It is like they put the 64bit System 32 over 0x6b00 (maybe) and the WoW64 over 0x7000 But I guess that ALSR can play around that numbers. There is still a way to disable ALSR? Corinna Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
On Jul 8 18:03, Marco Atzeri wrote: > Am 30.06.2018 um 22:47 schrieb Ken Brown: > > On 6/30/2018 11:52 AM, Marco Atzeri wrote: > > > > I've never had this problem with my own 32bit installation on W10, but I > > just reproduced it by doing a new installation with your list of > > packages. Have you tried just installing a minimal list of packages > > that you need for building the packages you maintain? > > > > On a fresh minimal installation the problem can arise again > > $ cygcheck -cd |wc -l > 245 > > as the first system shared libs are lower than the rebase > DefaultBaseAddress=0x07000 > > 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll > 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll > > I think that rebase should consider different rebase > base address for W10. > > Using DefaultBaseAddress=0x06F00 seems fine > for the time being I can do that in the rebaseall script (I have a matching patch locally), but it looks like a race we can't win in the long run. 240 Megs less space is a lot given the number of DLLs in the distro. To make matters worse, I just checked my local 32 bit W10 and it turns out that various Windows DLLs loaded by default (even in a simple tcsh) are at even lower addresses, e.g. 6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Fork issue on W10 WOW
Am 30.06.2018 um 22:47 schrieb Ken Brown: On 6/30/2018 11:52 AM, Marco Atzeri wrote: I've never had this problem with my own 32bit installation on W10, but I just reproduced it by doing a new installation with your list of packages. Have you tried just installing a minimal list of packages that you need for building the packages you maintain? On a fresh minimal installation the problem can arise again $ cygcheck -cd |wc -l 245 as the first system shared libs are lower than the rebase DefaultBaseAddress=0x07000 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll I think that rebase should consider different rebase base address for W10. Using DefaultBaseAddress=0x06F00 seems fine for the time being Edition: Windows W10 Home Version: 1709 Betriebssystembuild/Operation system build: 16299.492 Regards Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
Am 30.06.2018 um 22:47 schrieb Ken Brown: On 6/30/2018 11:52 AM, Marco Atzeri wrote: Hi, on a new W10 HP Laptop, the 32 bit installation always fails on postinstallation scripts that use perl. The outcome is like: $ ./texlive-collection-formatsextra.sh 1 [main] perl 1796 child_info_fork::abort: address space needed by 'Encode.dll' (0x262) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/fmtutil line 73. [...] Until I have the 32bit running I can not deploy any new package, as the previous W7 is retired. I've never had this problem with my own 32bit installation on W10, but I just reproduced it by doing a new installation with your list of packages. Have you tried just installing a minimal list of packages that you need for building the packages you maintain? partially tried, and the minimal installation was fine. Alternatively, you might work around the problem by first doing a base install, then installing your texlive-collection-* packages, and then installing everything else. I just tested this with your list of packages, and it worked for me. I will give a try to this sequence. Ken Thanks for your experiment Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- 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: Fork issue on W10 WOW
On 6/30/2018 11:52 AM, Marco Atzeri wrote: Hi, on a new W10 HP Laptop, the 32 bit installation always fails on postinstallation scripts that use perl. The outcome is like: $ ./texlive-collection-formatsextra.sh 1 [main] perl 1796 child_info_fork::abort: address space needed by 'Encode.dll' (0x262) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/fmtutil line 73. [...] Until I have the 32bit running I can not deploy any new package, as the previous W7 is retired. I've never had this problem with my own 32bit installation on W10, but I just reproduced it by doing a new installation with your list of packages. Have you tried just installing a minimal list of packages that you need for building the packages you maintain? Alternatively, you might work around the problem by first doing a base install, then installing your texlive-collection-* packages, and then installing everything else. I just tested this with your list of packages, and it worked for me. Ken -- 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: Fork issue on W10 WOW
Marco Atzeri writes: > on a new W10 HP Laptop, the 32 bit installation always fails > on postinstallation scripts that use perl. Please check if that installation has activated the option of forcing ASLR on everything (even if explicitly marked non-ASRL aware). > It is not due to an Antivirus as after testing two I tested without > any one installed and the outcome is unchanged. Certain stuff previously done in Defender or EMET (which is phased out for Win10) is now built into Windows and so can no longer be uninstalled. > The 64bit installation seems fine. > > Suggestion ? > > Until I have the 32bit running I can not deploy any new package, as > the previous W7 is retired. If all else fails, try a VHD installation or VM with Server 2016 LTSB Evaluation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Fork issue on W10 WOW
On 2018-06-30 09:52, Marco Atzeri wrote: > Hi, > on a new W10 HP Laptop, the 32 bit installation always fails > on postinstallation scripts that use perl. > > The outcome is like: > > $ ./texlive-collection-formatsextra.sh > 1 [main] perl 1796 child_info_fork::abort: address space needed by > 'Encode.dll' (0x262) is already occupied > Can't fork, trying again in 5 seconds at /usr/bin/fmtutil line 73. > > I did a snapshot dll address using ProcessExplorer, and it > it seems that when running perl the relevant dll's are loaded low > also when nothing seems on their expected address > > Encode.dll > D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\Encode\Encode.dll > > 0x270 0x1 > MD5.dll > D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\Digest\MD5\MD5.dll > > 0x271 0xE000 > Fcntl.dll > D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\Fcntl\Fcntl.dll > > 0x272 0xD000 > IO.dll D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\IO\IO.dll > 0x273 0xD000 > Util.dll > D:\cygwin32\lib\perl5\vendor_perl\5.26\i686-cygwin-threads-64int\auto\List\Util\Util.dll > 0x2E4 0x13000 > Glob.dll > D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\File\Glob\Glob.dll > > 0x2E6 0xF000 > Storable.dll > D:\cygwin32\lib\perl5\5.26\i686-cygwin-threads-64int\auto\Storable\Storable.dll > 0x2E7 0x2 > > It is not due to an Antivirus as after testing two I tested without > any one installed and the outcome is unchanged. > > The 64bit installation seems fine. > > Suggestion ? > > Until I have the 32bit running I can not deploy any new package, as the > previous > W7 is retired. Does cygwin32 support exes/dlls with peflags -l --bigaddr set to allow them to use 4GB on x64 (3GB on x86 with boot.ini /3GB set) and does rebase 32 support this? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
