assertion "p >= path" failed

assertion "p >= path" failed

[Tim Adye]

Hi again,

Thanks for all the interesting detective work investigating my problem 
with ssh-agent. Let's hope it results in a fix.

I have another problem which is a bit harder to reproduce, but perhaps 
has a clearer signature. From time to time my PC gets into a state where 
no Cygwin command will start. They all exit with the message:

C:\>C:\cygwin\bin\bash.exe
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&)

It's the same result whatever Cygwin command is used and whatever 
directory I start from. Already-running commands still seem to work (eg. 
connecting to sshd gets as far as a password prompt), but they can't 
start anything new. Even if I exit/kill all Cygwin processes (including 
sshd service), it remains in this broken state. The only fix I have 
found is to reboot the machine. After that Cygwin works fine.

I'm not entirely sure what prompts the issue, but it seems to be 
associated with resuming from hibernation in a different location, 
perhaps after going from online to offline. I use Offline Files for my 
Cygwin HOME directory. I also sometimes get hangups with other programs, 
or even the Windows desktop, after resuming from hibernation, so this 
may be indicative of a more general problem. Cygwin's issue is the 
clearest example, so I'll start here.

Do you have any ideas how I can diagnose or fix this? I'm using 64-bit 
Cygwin 3.0.7-1.

Thanks,
Tim.

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

Re: assertion "p >= path" failed

[Ken Brown]

On 10/25/2019 6:07 PM, Tim Adye wrote:
> Hi again,
> 
> Thanks for all the interesting detective work investigating my problem with 
> ssh-agent. Let's hope it results in a fix.
> 
> I have another problem which is a bit harder to reproduce, but perhaps has a 
> clearer signature. From time to time my PC gets into a state where no Cygwin 
> command will start. They all exit with the message:
> 
> C:\>C:\cygwin\bin\bash.exe
> 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&)

This might be the same bug that was reported here:

   https://cygwin.com/ml/cygwin/2019-09/msg00228.html .

That bug has been fixed.  Please try the test release cygwin-3.1.0-0.7 and see 
if you still have the problem.

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

Re: assertion "p >= path" failed

[Tim Adye]

Hi Ken,

Thanks for the promising idea. I could reproduce the assertion with the 
examples like '\\?\DRIVE' given in the other thread, so I have now 
upgraded to cygwin-3.1.0-0.7. This fixes the '\\?\DRIVE' assertion. 
Since my case only happens from time to time, I'll have to wait and see 
if it happens again. I'll let you know if it does.

Thanks,
Tim.

On 26/10/2019 02:00, Ken Brown wrote:
> On 10/25/2019 6:07 PM, Tim Adye wrote:
>> Hi again,
>>
>> Thanks for all the interesting detective work investigating my problem with
>> ssh-agent. Let's hope it results in a fix.
>>
>> I have another problem which is a bit harder to reproduce, but perhaps has a
>> clearer signature. From time to time my PC gets into a state where no Cygwin
>> command will start. They all exit with the message:
>>
>> C:\>C:\cygwin\bin\bash.exe
>> 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&)
> This might be the same bug that was reported here:
>
>     https://cygwin.com/ml/cygwin/2019-09/msg00228.html .
>
> That bug has been fixed.  Please try the test release cygwin-3.1.0-0.7 and see
> if you still have the problem.
>
> 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
>


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

Re: assertion "p >= path" failed

[Tim Adye]

Hi Ken,

I'm afraid I get a very similar error with 3.1.0-0.7:

assertion "p >= path" failed: file 
"/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.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&)

Again following resume from hibernation after going offline with the 
offline files as HOME (H:\). Again the only way out of the issue is to 
reboot.

Any other ideas to help me diagnose?

Thanks,
Tim.

On 26/10/2019 22:15, Tim Adye wrote:
> Hi Ken,
>
> Thanks for the promising idea. I could reproduce the assertion with 
> the examples like '\\?\DRIVE' given in the other thread, so I have now 
> upgraded to cygwin-3.1.0-0.7. This fixes the '\\?\DRIVE' assertion. 
> Since my case only happens from time to time, I'll have to wait and 
> see if it happens again. I'll let you know if it does.
>
> Thanks,
> Tim.
>
> On 26/10/2019 02:00, Ken Brown wrote:
>> On 10/25/2019 6:07 PM, Tim Adye wrote:
>>> Hi again,
>>>
>>> Thanks for all the interesting detective work investigating my 
>>> problem with
>>> ssh-agent. Let's hope it results in a fix.
>>>
>>> I have another problem which is a bit harder to reproduce, but 
>>> perhaps has a
>>> clearer signature. From time to time my PC gets into a state where 
>>> no Cygwin
>>> command will start. They all exit with the message:
>>>
>>> C:\>C:\cygwin\bin\bash.exe
>>> 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&)
>> This might be the same bug that was reported here:
>>
>> https://cygwin.com/ml/cygwin/2019-09/msg00228.html .
>>
>> That bug has been fixed.  Please try the test release 
>> cygwin-3.1.0-0.7 and see
>> if you still have the problem.
>>
>> 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
>>
>
>
> -- 
> 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
>


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

Re: assertion "p >= path" failed

[Ken Brown]

[Please don't top-post on this list.  Thanks.]

On 10/30/2019 7:56 PM, Tim Adye wrote:
> I'm afraid I get a very similar error with 3.1.0-0.7:
> 
> assertion "p >= path" failed: file 
> "/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.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&)

OK, so your issue is different from the one that was fixed.

> Again following resume from hibernation after going offline with the offline 
> files as HOME (H:\).

I'm not familiar with offline files, so it would help if you would explain this 
in complete detail.

It would also help if you could capture the assertion failure in a debugger.  Do 
you know how to use gdb?  If so, I would suggest attaching gdb to bash before 
hibernating, and putting a breakpoint at symlink_info::check.  Assuming that gdb 
is still usable after you resume from hibernation, we ought to be able to find 
the cause of the assertion failure.

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

Re: assertion "p >= path" failed

[Tim Adye]

Hi Ken,

On 31/10/2019 18:19, Ken Brown wrote:
> [Please don't top-post on this list.  Thanks.]
>
> On 10/30/2019 7:56 PM, Tim Adye wrote:
>> I'm afraid I get a very similar error with 3.1.0-0.7:
>>
>> assertion "p >= path" failed: file
>> "/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.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&)
> OK, so your issue is different from the one that was fixed.
>
>> Again following resume from hibernation after going offline with the offline
>> files as HOME (H:\).
> I'm not familiar with offline files, so it would help if you would explain this
> in complete detail.

Offline Files is a feature of Sync Center that makes network files 
available to a user, even if the network connection to the server is 
unavailable. Windows keeps a copy of files stored on the network on the 
local computer. This allows users to work with them even when they are 
not connected to the network or a server is unavailable. The next time 
the user connects to the network or the server is available, their 
offline files on your computer will automatically sync to the network 
files on the server.

I have it set up to keep a local copy of a mapped network drive that 
holds my files (Cygwin $HOME). As I understand it (eg. explained in 
https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/folder-redirection-rup-overview), 
when the system goes offline, Windows uses the "Folder Redirection" 
feature to redirect access to the client-side cache, C:\Windows\CSC.

I guess Cygwin can choke on this redirected path.
> It would also help if you could capture the assertion failure in a debugger.  Do
> you know how to use gdb?  If so, I would suggest attaching gdb to bash before
> hibernating, and putting a breakpoint at symlink_info::check.  Assuming that gdb
> is still usable after you resume from hibernation, we ought to be able to find
> the cause of the assertion failure.

I will try this, but it will be tricky, because I don't get the 
assertion every time I go offline / hibernate. I'll see if I can work 
out how to provoke the bug reliably. I don't remember the situation from 
every time it's happened, but I think perhaps it can happen if there is 
a bash window open at the time. bash still works, but it can't run 
anything else, nor can I start any new processes. If so, your test might 
be possible, but might not see the symptom, since the problem seems to 
be in processes started by bash. But I'll try.

Thanks,
Tim.
> 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
>


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

Re: assertion "p >= path" failed

[Ken Brown]

On 11/4/2019 7:49 AM, Tim Adye wrote:
> Hi Ken,
> 
> On 31/10/2019 18:19, Ken Brown wrote:
>> [Please don't top-post on this list.  Thanks.]
>>
>> On 10/30/2019 7:56 PM, Tim Adye wrote:
>>> I'm afraid I get a very similar error with 3.1.0-0.7:
>>>
>>> assertion "p >= path" failed: file
>>> "/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.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&)
>> OK, so your issue is different from the one that was fixed.
>>
>>> Again following resume from hibernation after going offline with the offline
>>> files as HOME (H:\).
>> I'm not familiar with offline files, so it would help if you would explain this
>> in complete detail.
> 
> Offline Files is a feature of Sync Center that makes network files available to 
> a user, even if the network connection to the server is unavailable. Windows 
> keeps a copy of files stored on the network on the local computer. This allows 
> users to work with them even when they are not connected to the network or a 
> server is unavailable. The next time the user connects to the network or the 
> server is available, their offline files on your computer will automatically 
> sync to the network files on the server.
> 
> I have it set up to keep a local copy of a mapped network drive that holds my 
> files (Cygwin $HOME). As I understand it (eg. explained in 
> https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/folder-redirection-rup-overview), 
> when the system goes offline, Windows uses the "Folder Redirection" feature to 
> redirect access to the client-side cache, C:\Windows\CSC.
> 
> I guess Cygwin can choke on this redirected path.
>> It would also help if you could capture the assertion failure in a debugger.  Do
>> you know how to use gdb?  If so, I would suggest attaching gdb to bash before
>> hibernating, and putting a breakpoint at symlink_info::check.  Assuming that gdb
>> is still usable after you resume from hibernation, we ought to be able to find
>> the cause of the assertion failure.
> 
> I will try this, but it will be tricky, because I don't get the assertion every 
> time I go offline / hibernate. I'll see if I can work out how to provoke the bug 
> reliably. I don't remember the situation from every time it's happened, but I 
> think perhaps it can happen if there is a bash window open at the time. bash 
> still works, but it can't run anything else, nor can I start any new processes. 
> If so, your test might be possible, but might not see the symptom, since the 
> problem seems to be in processes started by bash. But I'll try.

Hi Tim,

I don't know if you noticed the thread starting here:

   https://cygwin.com/ml/cygwin/2019-12/msg00016.html

The problem reported there has been fixed, and I hope that the fix also works 
for your problem.  You can test it by installing the latest snapshot from 
https://cygwin.com/snapshots/.

Thanks.

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

Re: assertion "p >= path" failed

[Tim Adye]

Hi Ken,

On 11/12/2019 16:03, Ken Brown wrote:
> On 11/4/2019 7:49 AM, Tim Adye wrote:
>> Hi Ken,
>>
>> On 31/10/2019 18:19, Ken Brown wrote:
>>> [Please don't top-post on this list.  Thanks.]
>>>
>>> On 10/30/2019 7:56 PM, Tim Adye wrote:
>>>> I'm afraid I get a very similar error with 3.1.0-0.7:
>>>>
>>>> assertion "p >= path" failed: file
>>>> "/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.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&)
>>> OK, so your issue is different from the one that was fixed.
>>>
>>>> Again following resume from hibernation after going offline with the offline
>>>> files as HOME (H:\).
>>> I'm not familiar with offline files, so it would help if you would explain this
>>> in complete detail.
>> Offline Files is a feature of Sync Center that makes network files available to
>> a user, even if the network connection to the server is unavailable. Windows
>> keeps a copy of files stored on the network on the local computer. This allows
>> users to work with them even when they are not connected to the network or a
>> server is unavailable. The next time the user connects to the network or the
>> server is available, their offline files on your computer will automatically
>> sync to the network files on the server.
>>
>> I have it set up to keep a local copy of a mapped network drive that holds my
>> files (Cygwin $HOME). As I understand it (eg. explained in
>> https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/folder-redirection-rup-overview),
>> when the system goes offline, Windows uses the "Folder Redirection" feature to
>> redirect access to the client-side cache, C:\Windows\CSC.
>>
>> I guess Cygwin can choke on this redirected path.
>>> It would also help if you could capture the assertion failure in a debugger.  Do
>>> you know how to use gdb?  If so, I would suggest attaching gdb to bash before
>>> hibernating, and putting a breakpoint at symlink_info::check.  Assuming that gdb
>>> is still usable after you resume from hibernation, we ought to be able to find
>>> the cause of the assertion failure.
>> I will try this, but it will be tricky, because I don't get the assertion every
>> time I go offline / hibernate. I'll see if I can work out how to provoke the bug
>> reliably. I don't remember the situation from every time it's happened, but I
>> think perhaps it can happen if there is a bash window open at the time. bash
>> still works, but it can't run anything else, nor can I start any new processes.
>> If so, your test might be possible, but might not see the symptom, since the
>> problem seems to be in processes started by bash. But I'll try.
> Hi Tim,
>
> I don't know if you noticed the thread starting here:
>
>     https://cygwin.com/ml/cygwin/2019-12/msg00016.html
>
> The problem reported there has been fixed, and I hope that the fix also works
> for your problem.  You can test it by installing the latest snapshot from
> https://cygwin.com/snapshots/.

Hi Ken,

Many thanks for the interesting and encouraging pointer. That does look 
similar to my issue, though I think the other issue was (originally at 
least) something to do with inaccessible mounts, rather than cached mounts.

I have tested the new snapshot and don't see any problems so far. 
However I have been having trouble reproducing my original issue, 
especially since I recreated my offline-files synchronisation 
partnership, so I can't tell for sure whether the update fixes my 
particular problem, or it just went away of its own accord. I'll keep 
exercising it and let you know if I see any more the assertion crash.

Thanks,
Tim.

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