DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; q=dns; s=default; b=ReLkbxKjavxJlomomeK+tBs81qYTA
	pgbfhp8+CcS+Sj2hD6M7nhnoUigIA7vxMRZVwW9ONTKhwGTEerhM/lOoLfT/KRYj
	871hD5/325XAEWfjojyTkSTLFyifPXlwmtW4DFeDouX7e73j6dzmQcsaJocNsJ8f
	qwD2V57SnM4rB8=
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
From: Ken Brown <kbrown AT cornell DOT edu>
To: "cygwin AT cygwin DOT com" <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
Date: Wed, 4 Dec 2019 16:39:53 +0000
Message-ID: <86a11527-94eb-f5ea-e295-3f4ed08a321e@cornell.edu>
References: <20191204104040 DOT GA11660 AT shackleton DOT labs DOT net> <b80a3dd2-b1d3-ab99-a8e3-12c9b2d44e46 AT cornell DOT edu> <20191204161846 DOT GA1509 AT shackleton DOT labs DOT net>
In-Reply-To: <20191204161846.GA1509@shackleton.labs.net>
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
received-spf: None (protection.outlook.com: cornell.edu does not designate permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3CDE8A7D6D145A46A16B8FAD20EC8C92 AT namprd04 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-userprincipalname: qTvpDSMNnTMGwBYhV7Ckxe1TCqefF2Uze8l3DZgJKlBln5h/bhJsXox/oZ8hLGJIkDJ5OgHL16EOX0/8CP7nWQ==
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id xB4GeYo0024553

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