This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build
- From: Ken Brown <kbrown at cornell dot edu>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Wed, 4 Dec 2019 16:39:53 +0000
- Subject: Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JZXjK+WV07Gr25z3wWaD9NOj83ezWE7goU0Uz2+wpNA=; b=oc9Chx8GrR+ruPrrEcoXCWBSBzvPi7zNduzIQW1GUOQsw7WvV3FHWaqyhWFwahME8vz53OaZnzBACXGcnG3KbL43q0qldUzUpj85z0jR3iQq6d5bgS46cFXjCmxAijA9uqOF8/M4ryFp5GZZbc3mG9sHXSRNqVgFYvWHUYsV8D74tJfROkjCI371LuAe34+dpzPjj0Qb4VCsIGGiECGqaqApqbu24eAXJhoYNMtniystqQYfPTroUgn8AQ7xR9IOGDJdzAx/P2Q/KDHgAecPEydYrI53KSSaHym6sA4k/nxvUUMDekCxeof7KBT1r7JNtPKYJAzcL/4i1PwQuLczeQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kFAOW9neiFQcXr6aH26Cnx4qrPz7OXnNDru6JCeO3jrsyFTEvEuXifb4d+cjUhaX6ItJIooYV6/khwJPaXP/6NlzUJb0zGBMysGzIUirVnxdTnXxCnbsjYsyT8P8S8X8F1FnJPtSvnkJUBNSnEjPZDL0wj39nZboewNeAWHgDitn4K8exc1rCwULR6xCVho53s5JpOF3DbfkKK+NupAK/6KABHoMQzwRigrx+9ZeZfjquqUsCNmFbkhecYXmmqOVdQND7uRrXUXIKHRWGPvebdtApiBFSWVKgvMR3fd/SjNw7KD9S4JhDrag0B/aGJHjIy0LZkvg/mRlZY0RhNlUiA==
- References: <20191204104040.GA11660@shackleton.labs.net> <b80a3dd2-b1d3-ab99-a8e3-12c9b2d44e46@cornell.edu> <20191204161846.GA1509@shackleton.labs.net>
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