X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4AD7C26A.70505@gmail.com>
Date: Fri, 16 Oct 2009 01:46:34 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: fork failure?
References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> <4AD73B83 DOT 9060505 AT gmail DOT com> <4AD74586 DOT 8070803 AT cwilson DOT fastmail DOT fm> <4AD752C8 DOT 2040908 AT gmail DOT com> <4AD7B135 DOT 6020401 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4AD7B135.6020401@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Charles Wilson wrote:

> 43673	6:58:17.3634216 PM	gpg-agent.exe	568	CreateFile	C:\cygwin-1.7
> SUCCESS	Desired Access: Execute/Traverse, Synchronize, Disposition:
> Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a,
> ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened	7628

> 43674	6:58:17.3634756 PM	gpg-agent.exe	568	CloseFile	C:\cygwin-1.7
> SUCCESS		7628

  And then "boom".  I suspect that must be:

>       status = NtOpenFile (&h, SYNCHRONIZE | FILE_TRAVERSE, &attr, &io,
> 			   FILE_SHARE_VALID_FLAGS,
> 			   FILE_DIRECTORY_FILE
> 			   | FILE_SYNCHRONOUS_IO_NONALERT
> 			   | FILE_OPEN_FOR_BACKUP_INTENT);
>       if (!NT_SUCCESS (status))
> 	{
> 	  RtlReleasePebLock ();
> 	  __seterrno_from_nt_status (status);
> 	  res = -1;
> 	  goto out;
> 	}
>       /* Workaround a problem in Vista/Longhorn which fails in subsequent
> 	 calls to CreateFile with ERROR_INVALID_HANDLE if the handle in
> 	 CurrentDirectoryHandle changes without calling SetCurrentDirectory,
> 	 and the filename given to CreateFile is a relative path.  It looks
> 	 like Vista stores a copy of the CWD handle in some other undocumented
> 	 place.  The NtClose/DuplicateHandle reuses the original handle for
> 	 the copy of the new handle and the next CreateFile works.
> 	 Note that this is not thread-safe (yet?) */
>       NtClose (*phdl);
>       if (DuplicateHandle (GetCurrentProcess (), h, GetCurrentProcess (), phdl,
> 			   0, TRUE, DUPLICATE_SAME_ACCESS))
> 	NtClose (h);
>       else
> 	*phdl = h;
>       dir = *phdl;

  I'd investigate phdl.  What OS version are you using?  32- or 64-bit?  Have
we possibly got the wrong packing or alignment of the PEB structure or
something like that?  I'm not sure if I'm reading it right (or if the sources
are necessarily correct), but

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/PEB.html

> typedef struct _PEB {
>   BOOLEAN InheritedAddressSpace;
>   BOOLEAN ReadImageFileExecOptions;
>   BOOLEAN BeingDebugged;
>   BOOLEAN Spare;
>   HANDLE Mutant;
>   PVOID ImageBaseAddress;
>   PPEB_LDR_DATA LoaderData;
>   PRTL_USER_PROCESS_PARAMETERS ProcessParameters;

http://www.nirsoft.net/kernel_struct/vista/PEB.html

> typedef struct _PEB
> {
>      UCHAR InheritedAddressSpace;
>      UCHAR ReadImageFileExecOptions;
>      UCHAR BeingDebugged;
>      UCHAR BitField;
>      ULONG ImageUsesLargePages: 1;
>      ULONG IsProtectedProcess: 1;
>      ULONG IsLegacyProcess: 1;
>      ULONG IsImageDynamicallyRelocated: 1;
>      ULONG SpareBits: 4;
>      PVOID Mutant;
>      PVOID ImageBaseAddress;
>      PPEB_LDR_DATA Ldr;
>      PRTL_USER_PROCESS_PARAMETERS ProcessParameters;


  Now is it just my imagination, or does Vista really insert an extra ULONG
bitfield at offset 4 in the struct resulting in all subsequent members being
offset by 4 relative to other versions of Windows?  This needs verifying
against the official MS headers.

    cheers,
      DaveK


--
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