DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:to:subject:message-id
	:reply-to:mime-version:content-type; q=dns; s=default; b=qbS7GZN
	9sOBYHXHpcS95URrd2VJ4bERTexvIASe3n/6EnfzuNmyK5pzxGmPkVyRnDaJYw6s
	sd5+KAFJxJKLCoi+byIql6cVZ+9vvZGq59bc/1Gf7uBqHOXUCqmtk0EHC2I1WFJ6
	CL+yafjBQpQeg0+HIiS8JreCN2gj3N19NvsM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 4 Dec 2019 17:17:43 +0000
From: "Wilfed Olaf Sulla via cygwin" <cygwin AT cygwin DOT com>
Reply-To: Wilfed Olaf Sulla <olaf DOT sulla AT btinternet DOT com>
To: Cygwin <cygwin AT cygwin DOT com>
Subject: Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build
Message-ID: <20191204171743.GA1994@shackleton.labs.net>
Reply-To: Wilfed Olaf Sulla <olaf DOT sulla AT btinternet DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.12.1 (2019-06-15)

>On 12/4/2019 11:18 AM, Wilfed Olaf Sulla via cygwin wrote:
>> On Wed 2019-12-04 14:40:18 +0000, Ken Brown wrote:
>>> On 12/4/2019 5:40 AM, Wilfed Olaf Sulla via cygwin wrote:
>>>> Hi,
>>>>
>>>> Cygwin is core dumping with the following message:
>>>>
>>>> assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 2916, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&)
>>>>
>>>>
>>>> To recreate this event:
>>>>
>>>> shackleton:sulla:$ cd /cygdrive/
>>>> shackleton:sulla:$ ls -la
>>>>
>>>>
>>>> Build:
>>>>
>>>> CYGWIN_NT-6.1 shackleton 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin
>>>> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
>>>>
>>>> -	Yes, it is an old machine that has been around for a while, but it
>>>> 	does the job asked of it.
>>>>
>>>>
>>>> A similar event seems to have cropped up before, with a pair of patches
>>>> following:
>>>>
>>>> 	Re: winsup\cygwin\path.cc issues
>>>> 	https://sourceware.org/ml/cygwin/2018-05/msg00315.html
>>>>
>>>> 	Cygwin: normalize_win32_path: Avoid buffer underruns
>>>> 	https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=35998fc2fa6c
>>>
>>> There was also a more recent example:
>>>
>>>       https://cygwin.com/ml/cygwin/2019-09/msg00228.html ,
>>>
>>> which was fixed here:
>>>
>>>       https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=283cb372e
>>>
>>> Please try the test release cygwin-3.1.0-0.8 to see if the fix also works for
>>> your case.  If not, can you figure out which file in /cygdrive causes the
>>> assertion failure?
>>>
>>> Ken
>> 
>> Many thanks.
>> 
>> I have installed cygwin-3.1.0-0.8 and re-run the steps without issue.
>> 
>> I looked into this a bit further: the path /cygdrive/ just contains
>> virtual drives mapped onto network shares thus:
>> 
>> shackleton:sulla:$ ls
>> c  e  g  v  w  x  y  z
>> 
>> C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto)
>> E: on /cygdrive/e type vfat (binary,noacl,posix=0,user,noumount,auto)
>> G: on /cygdrive/g type ntfs (binary,noacl,posix=0,user,noumount,auto)
>> V: on /cygdrive/v type smbfs (binary,noacl,posix=0,user,noumount,auto)
>> W: on /cygdrive/w type smbfs (binary,noacl,posix=0,user,noumount,auto)
>> X: on /cygdrive/x type smbfs (binary,noacl,posix=0,user,noumount,auto)
>> Y: on /cygdrive/y type smbfs (binary,noacl,posix=0,user,noumount,auto)
>> Z: on /cygdrive/z type cifs (binary,noacl,posix=0,user,noumount,auto)
>> 
>> The network shares were created via Explorer.
>> 
>> 
>> So long as all the network shares are accessible there is no problem, however
>> if /cygdrive/z is off-line - as was the case when I first encountered
>> the problem
>
>In that case, this is probably the same problem that was reported in
>
>   https://cygwin.com/ml/cygwin/2019-10/msg00155.html,
>
>which has not yet been solved.
>
>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
>

Thanks,

Hibernation is disabled on the device so that is not a factor in this
instance. However, the absence of the network share is the factor that
can be directly attributed to the cause of the aborted core dump in the
above.

The call to 'NtCreateFile' on the Z: drive (on the network share that is
offline) triggers the abort in 'ls'. This call appears to be made even 
though the Z: drive is not listed by mount. Other than that, my
knowledge of the internals is insufficient to either suggest the exact 
cause or a potential solution.

However we know that there is a problem in this area and that it can be
avoided until such time as a fix might become available.

Many thanks for your help.

-- 

Mutt 1.12.1 (2019-06-15)

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