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 - although it was not listed in the output of 'mount', it was 
according to an strace of the 'ls' command still being passed through 
'normalize_win32_path' (see attached) and thus causing the aborted coredump:

shackleton:sulla:$ cd /cygdrive/
shackleton:sulla:$ ls -la
assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.1.0/cygwin-3.1.0-0.8.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 2906, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&)


-- 

Mutt 1.12.1 (2019-06-15)