On Feb 20 10:33, Kevin Ushey via Cygwin wrote:
> Hi Corinna,
>
> I just updated
> https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce
> with that output (windbg-output-2.txt); let me know if that gives you
> what you need.
Thank you! Not sure I'll follow up on this, ARM64 assemb
Hi Corinna,
I just updated
https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce
with that output (windbg-output-2.txt); let me know if that gives you
what you need.
As an aside, a new version of the Windows Insider edition was just
released, and the memory addresses for the stubs
Hi Kevin,
On Feb 15 20:13, Corinna Vinschen via Cygwin wrote:
> On Feb 15 09:46, Kevin Ushey via Cygwin wrote:
> > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
> [...]
> 0001`802b7054 db030094 bl ntdll!#RtlpReferenceCurrentDirectory
> (1802b7fc0)
I'm not famili
On Feb 15 09:46, Kevin Ushey via Cygwin wrote:
> Thanks -- I've put the associated WinDbg output up at
> https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
> (Sharing it externally just because it's relatively large.)
Thank you!
> The important thing to note is that #RtlGetCurre
Thanks -- I've put the associated WinDbg output up at
https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
(Sharing it externally just because it's relatively large.)
The important thing to note is that #RtlGetCurrentDirectory_U appears
to be valid ARM assembly, but not x86_64 asse
On Feb 14 13:49, Kevin Ushey via Cygwin wrote:
> Thanks for your patience. Here's what I've got for the assembly around
> get_dir. I added a bit of debug logging just so I could get the
> function addresses:
First of all, thanks for taking the time to debug this further!
> C:\cygwin\bin>cygpath
>
Thanks for your patience. Here's what I've got for the assembly around
get_dir. I added a bit of debug logging just so I could get the
function addresses:
C:\cygwin\bin>cygpath
get_dir = 0x7FFB85E251B0
rcall = 0x7FFB85E251CB
And here's what WinDbg reports:
ntdll!EXP+#RtlGetCurrentDirectory_U
On Feb 14 10:52, Corinna Vinschen via Cygwin wrote:
> On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> > Here's a bit more information from a debug build of cygwin; here I'm
> > just trying to launch cygpath.exe:
> >
> > (gdb) f 1
> > #1 0x7ffa0123ba1f in find_fast_cwd_pointer () at
> > ../..
On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> Here's a bit more information from a debug build of cygwin; here I'm
> just trying to launch cygpath.exe:
>
> (gdb) f 1
> #1 0x7ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> 4526 const uint8_t *lock
Here's a bit more information from a debug build of cygwin; here I'm
just trying to launch cygpath.exe:
(gdb) f 1
#1 0x7ffa0123ba1f in find_fast_cwd_pointer () at
../../../../winsup/cygwin/path.cc:4526
4526 const uint8_t *lock = (const uint8_t *)
(gdb) bt
#0 memmem (haystack=, hs_len=,
On Feb 13 10:01, Kevin Ushey via Cygwin wrote:
> On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen wrote:
> > On Feb 13 11:09, Corinna Vinschen via Cygwin wrote:
> > > Other than that, the only thing you really could do at this point is to
> > > check Cygwin's find_fast_cwd_pointer() function and go
Hi Corinna,
Thank you for taking a look so quickly -- I can confirm your patch
fixes things for me; the installer now runs to completion and the
Cygwin64 Terminal + other installed tools all function correctly.
Best,
Kevin
On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen
wrote:
>
> On Feb 13 11
On Feb 13 11:09, Corinna Vinschen via Cygwin wrote:
> On Feb 12 14:38, Kevin Ushey via Cygwin wrote:
> > For reference, I first bumped into this when using Git Bash as bundled
> > with Git for Windows, but it sounds like the underlying issue may be
> > in Cygwin. See https://github.com/git-for-wind
On Feb 12 14:38, Kevin Ushey via Cygwin wrote:
> Hello,
>
> I'm seeing an issue when attempting to install Cygwin where the
> installer hangs while trying to run postinstall scripts (more
> specifically, /etc/postinstall/0p_000_autorebase.dash). When the hang
> occurs, I see a 'dash.exe' process c
Hello,
I'm seeing an issue when attempting to install Cygwin where the
installer hangs while trying to run postinstall scripts (more
specifically, /etc/postinstall/0p_000_autorebase.dash). When the hang
occurs, I see a 'dash.exe' process chewing up 100% of a CPU. If I
attach to the process with Wi
15 matches
Mail list logo