Re: fork failure?

[Dave Korn <dave dot korn dot cygwin at googlemail 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