On Jun 7 08:42, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > The structure is allocated right after the space occupied by the DLL
> > itself, using VirtualAlloc. I changed the struct layout so that the
> > size depends on the length of the pathname to the DLL. In most, if not
> > all case
On Sun, Jun 07, 2009 at 10:23:08AM +0200, Corinna Vinschen wrote:
>The structure is allocated right after the space occupied by the DLL
>itself, using VirtualAlloc. I changed the struct layout so that the
>size depends on the length of the pathname to the DLL. In most, if not
>all cases this will
Andy Koppe wrote:
>> 2) if the length of the actual pathname to the DLL is more than 2k wide
>> characters (e.g. 4k bytes) then issue #1 is made increasingly likely,
>
> Surely anyone with paths like that deserves all the pain that comes
> their way. 2k characters means 85 levels of "Documents and
> 2) if the length of the actual pathname to the DLL is more than 2k wide
> characters (e.g. 4k bytes) then issue #1 is made increasingly likely,
Surely anyone with paths like that deserves all the pain that comes
their way. 2k characters means 85 levels of "Documents and Settings".
:)
Andy
--
U
Corinna Vinschen wrote:
> The structure is allocated right after the space occupied by the DLL
> itself, using VirtualAlloc. I changed the struct layout so that the
> size depends on the length of the pathname to the DLL. In most, if not
> all cases this will fit into a single 4K page.
...
> Howe
Corinna Vinschen wrote:
> The only difference of Vista/W7 to earlier system is the additional ASLR
> feature which could help to plaster over the issue in a non-reproducible
> way. */me ducks to escape Chucks slap*
No slap from me. Your analysis shows conclusively that ASLR is and
always was a re
On Jun 7 07:37, Ken Brown wrote:
> On 6/7/2009 4:23 AM, Corinna Vinschen wrote:
>> I tested this change on XP 32 bit, 2K8 32 bit, W7 32 bit, and W7 64 bit,
>> by running `cygport automake1.11 compile' and a subsequent `make check',
>> which uses perl (and thus run-time loaded DLLs) a lot.
>
> I do
On 6/7/2009 4:23 AM, Corinna Vinschen wrote:
I tested this change on XP 32 bit, 2K8 32 bit, W7 32 bit, and W7 64 bit,
by running `cygport automake1.11 compile' and a subsequent `make check',
which uses perl (and thus run-time loaded DLLs) a lot.
I don't have the expertise to follow this thread
On Jun 6 10:49, Corinna Vinschen wrote:
> On Jun 6 01:15, Dave Korn wrote:
> > Corinna Vinschen wrote:
> >
> > > Not good. I'm puzzled where this allocated 68K region is exactly coming
> > > from, but it really looks like something which occurs in or near dlopen.
> > >
> > > I'm going to debug
On Jun 6 01:15, Dave Korn wrote:
> Corinna Vinschen wrote:
>
> > Not good. I'm puzzled where this allocated 68K region is exactly coming
> > from, but it really looks like something which occurs in or near dlopen.
> >
> > I'm going to debug this further tomorrow. I guess that goes without
> >
Corinna Vinschen wrote:
> Not good. I'm puzzled where this allocated 68K region is exactly coming
> from, but it really looks like something which occurs in or near dlopen.
>
> I'm going to debug this further tomorrow. I guess that goes without
> saying, but I'd be glad for any help.
I'll ju
On Jun 5 14:44, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > However, if I rebase the DLL to some other spot, like 0x6500, then
> > the DLL is loaded at that address exactly, and everything works fine. I
> > still don't think this has anything to do with ASLR. ASLR only
> > complicate
Corinna Vinschen wrote:
> On Jun 5 10:56, Charles Wilson wrote:
>> You did reboot, right? IIRC Windows only calculates the new base
>
> No. Because *none* of my DLLs is marked to be ASLR compatible. I'm
> testing what happens OOTB.
OK, that makes sense.
> The entire problem starts already i
On 05/06/2009 11:35, Corinna Vinschen wrote:
Here's another thought:
I examined the address layout of the perl process again, and it struck
me as weird that the base addresses of all the DLLs which get dynamically
loaded by perl are so near together. It looks like the problem is
actually tighte
[Caution, another long reply. For those just looking for a simple
workaround, skip to line 86 of the mail body.]
On Jun 5 10:56, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > I can reproduce the "unable to remap" on W7RC by running `cygport
> > automake1.11-1.11-10 compile'.
>
> Uhhh...I
Corinna Vinschen wrote:
> I can reproduce the "unable to remap" on W7RC by running `cygport
> automake1.11-1.11-10 compile'.
Uhhh...I'm glad to hear that? Or not...
> The culprit in my case is always the
> same DLL, a run-time loaded perl DLL called Cwd.dll. Even after
> rebaseall, it still doe
On Jun 4 19:49, Yaakov S wrote:
> On 04/06/2009 14:28, Yaakov (Cygwin/X) wrote:
>> I'm having similar problems with Avast 4.8 Home Edition on Windows 7 RC
>> x64 with cygwin-1.7. I never had a problem with this A/V on XP with 1.5
>> or 1.7. This continues even after rebaseall and peflagsall. I hav
On 04/06/2009 14:28, Yaakov (Cygwin/X) wrote:
I'm having similar problems with Avast 4.8 Home Edition on Windows 7 RC
x64 with cygwin-1.7. I never had a problem with this A/V on XP with 1.5
or 1.7. This continues even after rebaseall and peflagsall. I have yet
to try removing Avast.
OK, I've un
On 04/06/2009 11:09, Charles Wilson wrote:
Well, you can never be SURE. I'd be surprised tho. I use AVG 8.5, which
doesn't cause any problems on my cygwin-1.5 installation under Vista,
nor on XP. Nobody has ever reported it as a BLODA before, AFAICT. It
does do on-access scanning, which means it
(please direct replies to the main cygwin list; I can't set reply-to on
this web interface...)
For context, see the bottom of this post:
http://cygwin.com/ml/cygwin-apps/2009-06/msg00048.html
Corinna wrote:
> I never, ever saw a problem like this on my Vista/2K8 test VMs. Nor on
> the W7 VMs. A
20 matches
Mail list logo
