Re: Installing Cygwin as normal user in nonstandard location?

[Martin Wege via Cygwin]

On Sun, May 26, 2024 at 7:35 PM Andrey Repin  wrote:
>
> Greetings, Martin Wege!
>
> >> Can Cygwin be installed as a normal user (without Admin rights) in a
> >> > nonstandard location, like C.\Users\martinwege\cygwinroot36\...)?
> >> >
> >> > Also, can this be done for more than one Cygwin version, e.g. I'd like
> >> > to test multiple Cygwin versions in parallel.
> >> >
> >>
> >> (?) Why ask when you can just try both scenarios pretty easily?
>
> > Simple example for possible issues (might be more):
> > Cygwin seems to modify the global REGISTRY with a "Install for
> > everyone" (as Admin). What will happen then?
>
> Why would you try to "install for everyone" if you don't have an admin rights?
>
> > Can Cygwin installations installed as non-admin interact via Windows
> > REGISTRY, or other unexpected ways?
>
> That's pretty strange question.

Why?

>
> > So testing by a non-expert like me might not uncover
> > such things immediately, so I better ask the experts here
>
> What do you ACTUALLY want to do?

We want to install multiple Cygwin installations, so we can do
(automated) regression testing. Also, the machines in question might
already have one admin-installed&approved Cygwin installation for all
users, which should not interact with any of the per-user
installations used for testing.

Thanks,
Martin

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Lemures Lemniscati via Cygwin]

On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
> On 5/26/2024 12:11 AM, Lemures Lemniscati via Cygwin wrote:
> > But, now, asy hangs after outputting a pdf.
> >
> > How to reproduce:
> >
> > 1. Prepare test.asy:
> >
> > // test.asy
> > dot((0,0));
> > // test.asy
> >
> > 2. `asy -vv test.asy` will successfully write test.eps.
> >
> > 3. But, `asy -vv -f pdf test.asy` will hang after gs produces test.pdf...
> 
> Sorry, I can't reproduce this on my system.  Can you attach gdb to the 
> hanging process to see where the hang occurs?

Here is a log from gdb. Will it help?
 run
 info threads
 info stack
 list


$ HOME=/tmp gdb --args asy -vv -f pdf test
GNU gdb (GDB) (Cygwin 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from asy...
Reading symbols from /usr/lib/debug//usr/bin/asy.exe.dbg...
(gdb) run
Starting program: /usr/bin/asy -vv -f pdf test
[New Thread 10728.0xa9c]
[New Thread 10728.0x3ed0]
[New Thread 10728.0xbd0]
[New Thread 10728.0x4c0c]
[New Thread 10728.0x2434]
[New Thread 10728.0x29d0]
[New Thread 10728.0x4ec8]
[New Thread 10728.0x2cfc]
[New Thread 10728.0x47bc]
[New Thread 10728.0x22d0]
[New Thread 10728.0x4268]
[New Thread 10728.0x2f94]
Using configuration directory /tmp/.asy
Using history /tmp/.asy/history
Welcome to Asymptote version 2.88
cd /tmp
Processing test
Loading plain from /usr/share/asymptote/plain.asy
Including plain_constants from /usr/share/asymptote/plain_constants.asy
Loading version from /usr/share/asymptote/version.asy
Including plain_strings from /usr/share/asymptote/plain_strings.asy
Including plain_pens from /usr/share/asymptote/plain_pens.asy
Including plain_paths from /usr/share/asymptote/plain_paths.asy
Including plain_filldraw from /usr/share/asymptote/plain_filldraw.asy
Including plain_margins from /usr/share/asymptote/plain_margins.asy
Including plain_picture from /usr/share/asymptote/plain_picture.asy
Loading plain_scaling from /usr/share/asymptote/plain_scaling.asy
Loading simplex from /usr/share/asymptote/simplex.asy
Loading plain_bounds from /usr/share/asymptote/plain_bounds.asy
Including plain_scaling from /usr/share/asymptote/plain_scaling.asy
Including plain_prethree from /usr/share/asymptote/plain_prethree.asy
Including plain_Label from /usr/share/asymptote/plain_Label.asy
Including plain_arcs from /usr/share/asymptote/plain_arcs.asy
Including plain_boxes from /usr/share/asymptote/plain_boxes.asy
Including plain_shipout from /usr/share/asymptote/plain_shipout.asy
Including plain_markers from /usr/share/asymptote/plain_markers.asy
Including plain_arrows from /usr/share/asymptote/plain_arrows.asy
Including plain_debugger from /usr/share/asymptote/plain_debugger.asy
Loading test from test.asy
gs -q -dNOPAUSE -dBATCH -P -dSAFER -dALLOWPSTRANSPARENCY -sDEVICE=pdfwrite 
-dEPSCrop -dSubsetFonts=true -dEmbedAllFonts=true -dMaxSubsetPct=100 
-dEncodeColorImages=true -dEncodeGrayImages=true -dCompatibilityLevel=1.5 
-dTransferFunctionInfo=/Apply -dAutoRotatePages=/None -g612x792 
-dDEVICEWIDTHPOINTS=3 -dDEVICEHEIGHTPOINTS=3 -sOutputFile=test.pdf -c .setsafe 
-f test_.eps
[Thread 10728.0x2434 exited with code 0]
[New Thread 10728.0x43cc]

Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 10728.0x4c0c]
0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(gdb) info threads
  Id   Target Id  Frame
  1Thread 10728.0x57c8 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  2Thread 10728.0xa9c 0x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3Thread 10728.0x3ed00x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4Thread 10728.0xbd0 0x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 5Thread 10728.0x4c0c "sig"  0x7ffd8487d313 in 
KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  7Thread 10728.0x29d0 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8Thread 10728.0x4ec8 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMu

Cygwin setup-x86_64.exe cannot install into UNC paths...

[Roland Mainz via Cygwin]

Hi!



I tried to install Cygwin on a network share using the UNC path name
(e.g. \\derfwnb4966_ipv4@2049\nfs4\storagetek\cygwintest001\), but got
this response: "The install directory must be absolute, with both a
drive letter and leading slash, like C:\Cygwin" ...
... is it possible to remove this restriction, so Cygwin can be
installed into UNC paths, please ?



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin setup-x86_64.exe cannot install into UNC paths...

[Roland Mainz via Cygwin]

On Mon, May 27, 2024 at 1:11 PM Roland Mainz  wrote:
> I tried to install Cygwin on a network share using the UNC path name
> (e.g. \\derfwnb4966_ipv4@2049\nfs4\storagetek\cygwintest001\), but got
> this response: "The install directory must be absolute, with both a
> drive letter and leading slash, like C:\Cygwin" ...
> ... is it possible to remove this restriction, so Cygwin can be
> installed into UNC paths, please ?

Quick&dirty workaround:
$ subst W: '\\derfwnb4966_ipv4@2049\nfs4\storagetek\cygwintest001\' # ...

... but then all hell breaks loose:
- snip 
# Cygwin version globally installed in C:\cygwin64 is
"3.6.0-0.115.g579064bf4d40.x86_64"
# Cygwin version installed in W:\ is 3.5.3-release
$ (export PATH=$PWD/bin ; ldd ./bin/file --help)
  1 [main] ldd (9340)
\\derfwnb4966_ipv4@2049\nfs4\storagetek\cygwintest001\bin\ldd.exe: ***
fatal error - fhandler size mismatch detected - 0x290/0x288.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

$ ldd ./bin/file
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffb59ef)
KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL
(0x7ffb595d)
KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll
(0x7ffb57a9)
cygmagic-1.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cygmagic-1.dll
(0x4d922)
cygwin1.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cygwin1.dll
(0x7ffb3924)
cyglzma-5.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cyglzma-5.dll
(0x59342)
cygbz2-1.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cygbz2-1.dll
(0x5bd7a)
cygz.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cygz.dll
(0x597fd)
cygzstd-1.dll =>
//derfwnb4966_ipv4@2049/nfs4/storagetek/cygwintest001/bin/cygzstd-1.dll
(0x5d515)
- snip 

Looking at |get_cygwin_startup_info()| - is it possible that somehow
the cygwin1.dll from Cygwin 3.5.3 and Cygwin 3.6 get mixed ?



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Installing Cygwin as normal user in nonstandard location?

[Roland Mainz via Cygwin]

On Sat, May 25, 2024 at 11:53 PM Martin Wege via Cygwin
 wrote:
> Can Cygwin be installed as a normal user (without Admin rights) in a
> nonstandard location, like C.\Users\martinwege\cygwinroot36\...)?
>
> Also, can this be done for more than one Cygwin version, e.g. I'd like
> to test multiple Cygwin versions in parallel.

I just started to experiment with that...
... please try this:
 snip 
setup-x86_64 --no-admin --no-write-registry --site
https://mirrors.kernel.org/sourceware/cygwin/ --root
'C.\Users\martinwege\cygwinroot36\' -P
cygwin,cygwin-devel,cygrunsrv,cygutils,cygutils-extra,bash,bzip2,coreutils,procps-ng,time,util-linux
 snip 



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Installing Cygwin as normal user in nonstandard location?

[Andrey Repin via Cygwin]

Greetings, Martin Wege!

> On Sun, May 26, 2024 at 7:35 PM Andrey Repin  wrote:
>>
>> Greetings, Martin Wege!
>>
>> >> Can Cygwin be installed as a normal user (without Admin rights) in a
>> >> > nonstandard location, like C.\Users\martinwege\cygwinroot36\...)?
>> >> >
>> >> > Also, can this be done for more than one Cygwin version, e.g. I'd like
>> >> > to test multiple Cygwin versions in parallel.
>> >> >
>> >>
>> >> (?) Why ask when you can just try both scenarios pretty easily?
>>
>> > Simple example for possible issues (might be more):
>> > Cygwin seems to modify the global REGISTRY with a "Install for
>> > everyone" (as Admin). What will happen then?
>>
>> Why would you try to "install for everyone" if you don't have an admin 
>> rights?
>>
>> > Can Cygwin installations installed as non-admin interact via Windows
>> > REGISTRY, or other unexpected ways?
>>
>> That's pretty strange question.

> Why?

Cygwin is a userland library and what you asking would be an exploit to the
underlying system.

>>
>> > So testing by a non-expert like me might not uncover
>> > such things immediately, so I better ask the experts here
>>
>> What do you ACTUALLY want to do?

> We want to install multiple Cygwin installations, so we can do
> (automated) regression testing. Also, the machines in question might
> already have one admin-installed&approved Cygwin installation for all
> users, which should not interact with any of the per-user
> installations used for testing.

If that admin-installed Cygwin version is out of control of your automated
testing setup, the chances it would interfere with it are far from zero.

My suggestion would be to not mess with user systems in such a way.
Use dedicated systems for automated testing.

If you still want your users to test with multiple Cygwin versions locally,
give them specific instructions to avoid collisions, s.a.:

  1. Clean environment.

%PATH%, %TEMP%, %TMP% and other relevant variables should not contain
reference to specific Cygwin installation. Use an appropriate CMD/PShell
wrapper script for environment sanitization to start testing instances.

  2.Clean start.

Don't launch Cygwin environments one from another. It IS possible to do so
cleanly, but better don't. Save your sanity.


-- 
With best regards,
Andrey Repin
Monday, May 27, 2024 15:58:34

Sorry for my terrible english...

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin setup-x86_64.exe cannot install into UNC paths...

[Andrey Repin via Cygwin]

Greetings, Roland Mainz!

> I tried to install Cygwin on a network share using the UNC path name

Very. Bad. Idea.

> (e.g. \\derfwnb4966_ipv4@2049\nfs4\storagetek\cygwintest001\), but got
> this response: "The install directory must be absolute, with both a
> drive letter and leading slash, like C:\Cygwin" ...
> ... is it possible to remove this restriction, so Cygwin can be
> installed into UNC paths, please ?

If your idea is to use same Cygwin install across multiple systems, then it is
a VERY bad idea. Due to the nature of fork call implementation in Cygwin, you
may experience unexpected behavior across different systems if DLL address
space layout come to be different from that where Cygwin was initially
installed.


-- 
With best regards,
Andrey Repin
Monday, May 27, 2024 16:15:05

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Ken Brown via Cygwin]

On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote:

On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
Here is a log from gdb. Will it help?
  run
  info threads
  info stack
  list


$ HOME=/tmp gdb --args asy -vv -f pdf test

[...]

Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.


I don't get this SIGRAP when I run the same command.  The program just 
runs to completion.  Maybe someone can explain what might cause this.  I 
have no idea.



[Switching to Thread 10728.0x4c0c]
0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(gdb) info threads
   Id   Target Id  Frame
   1Thread 10728.0x57c8 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2Thread 10728.0xa9c 0x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3Thread 10728.0x3ed00x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4Thread 10728.0xbd0 0x7ffd871b35a4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 5Thread 10728.0x4c0c "sig"  0x7ffd8487d313 in 
KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
   7Thread 10728.0x29d0 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8Thread 10728.0x4ec8 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   9Thread 10728.0x2cfc "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   10   Thread 10728.0x47bc "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   11   Thread 10728.0x22d0 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   12   Thread 10728.0x4268 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   13   Thread 10728.0x2f94 "asy"  0x7ffd871b04a4 in 
ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   14   Thread 10728.0x43cc "waitproc" 0x7ffd871af9d4 in 
ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll


The one thing that strikes me about this is the large number of "asy" 
threads.  There was a recent bug report about multithreading in 
cygwin-3.5.3:


  https://cygwin.com/pipermail/cygwin/2024-May/255987.html

Can you try installing a 3.4.x version of cygwin and see if you still 
get the hang?


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[Csaba Ráduly via Cygwin]

On 26/05/2024 14:03, Adam Dinwoodie via Cygwin wrote:

On Sun, 26 May 2024 at 05:10, David Dyck via Cygwin wrote:

I upgraded to the most recent git and I get the following error
(  stable2.45.1-1x86_648597 KiB2024-05-25 18:58 )

$ git clone -v https://github.com/lxml/lxml.git
Cloning into 'lxml'...
POST git-upload-pack (175 bytes)
POST git-upload-pack (gzip 8652 to 4281 bytes)
remote: Enumerating objects: 33933, done.
remote: Counting objects: 100% (3778/3778), done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
30155
Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done.
fatal: fetch-pack: invalid index-pack output

when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32
I was able to get the repository download

$ git clone -v https://github.com/lxml/lxml.git
Cloning into 'lxml'...
POST git-upload-pack (175 bytes)
POST git-upload-pack (gzip 8652 to 4281 bytes)
remote: Enumerating objects: 33933, done.
remote: Counting objects: 100% (3778/3778), done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
30155
Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done.
Resolving deltas: 100% (16518/16518), done.

Thanks for the report. This is working fine for me locally.


 Me too 

$ git --version
git version 2.45.1
$ git clone -v https://github.com/lxml/lxml.git
Cloning into 'lxml'...
POST git-upload-pack (175 bytes)
POST git-upload-pack (gzip 8652 to 4282 bytes)
remote: Enumerating objects: 33941, done.
remote: Counting objects: 100% (3786/3786), done.
remote: Compressing objects: 100% (1327/1327), done.
remote: Total 33941 (delta 2361), reused 3474 (delta 2244), pack-reused 
30155

Receiving objects: 100% (33941/33941), 20.20 MiB | 13.19 MiB/s, done.
Resolving deltas: 100% (16523/16523), done.

Csaba

--
Life is complex, with real and imaginary parts.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[Brian Inglis via Cygwin]

On 2024-05-26 16:44, David Dyck via Cygwin wrote:

After updating I still get the same error.

$ git clone -v https://github.com/lxml/lxml.git
Cloning into 'lxml'...
POST git-upload-pack (175 bytes)
POST git-upload-pack (gzip 8652 to 4282 bytes)
remote: Enumerating objects: 33941, done.
remote: Counting objects: 100% (3786/3786), done.
remote: Compressing objects: 100% (1328/1328), done.
remote: Total 33941 (delta 2360), reused 3474 (delta 2243), pack-reused
30155
Receiving objects: 100% (33941/33941), 20.20 MiB | 17.42 MiB/s, done.
fatal: fetch-pack: invalid index-pack output


$ cygcheck -srv >cygcheck.out
cygcheck: dump_sysinfo: GetVolumeInformation() for drive S: failed: 53

$ git --version
git version 2.45.1

$ cygcheck -c git
Cygwin Package Information
Package  VersionStatus
git  2.45.1-1   OK

$  type git
git is hashed (/usr/bin/git)

attached cygcheck.out


Retry running git prefixed with PATH=/usr/bin:/bin/:/usr/sbin:/sbin
ISTR in the past having to lose MS dirs from my Cygwin PATH.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[Adam Dinwoodie via Cygwin]

On Sun, 26 May 2024 at 23:45, David Dyck via Cygwin  wrote:
>
> After updating I still get the same error.
>
> $ git clone -v https://github.com/lxml/lxml.git
> Cloning into 'lxml'...
> POST git-upload-pack (175 bytes)
> POST git-upload-pack (gzip 8652 to 4282 bytes)
> remote: Enumerating objects: 33941, done.
> remote: Counting objects: 100% (3786/3786), done.
> remote: Compressing objects: 100% (1328/1328), done.
> remote: Total 33941 (delta 2360), reused 3474 (delta 2243), pack-reused
> 30155
> Receiving objects: 100% (33941/33941), 20.20 MiB | 17.42 MiB/s, done.
> fatal: fetch-pack: invalid index-pack output
>
>
> $ cygcheck -srv >cygcheck.out
> cygcheck: dump_sysinfo: GetVolumeInformation() for drive S: failed: 53
>
> $ git --version
> git version 2.45.1
>
> $ cygcheck -c git
> Cygwin Package Information
> Package  VersionStatus
> git  2.45.1-1   OK
>
> $  type git
> git is hashed (/usr/bin/git)
>
> attached cygcheck.out

I've just set up a test sandbox with the same set of Cygwin
applications installed, and I'm still not able to replicate this
failure, which is going to make it difficult to work out what's going
wrong for you!

I note your Cygwin PATH has several entries before /bin, including a
~/bin that apparently contains a perl executable; can you see if you
can reproduce the problem with a clean PATH?

In any case, I'm having to conclude the issue is something odd about
your environment that doesn't seem to be affecting most people.
Working out what's going wrong will probably require isolating what
difference is relevant here. I think there's two obvious routes to
doing that: you can work out what's odd about your environment (maybe
use Windows Sandbox, given you're running Windows Enterprise? I've
attached a .wsb file that should give you a starting point for setting
up test environments, based on your cygcheck.out), or you can work out
what's changed in Git between 2.42.0 and 2.45.1, which will probably
mean building and bisecting Git yourself; once we know what change is
the culprit, that'll make it much easier to work out what's going
wrong.

If it'd be useful, I can provide some test builds of Git to help
narrow down where the problem is, but if you can do the builds
yourself, that'll be a lot quicker than trying to do a binary chop by
email…


cygwintest.wsb
Description: Binary data

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[Dan Shelton via Cygwin]

I can replicate the 'fatal: fetch-pack: invalid index-pack output'
error with https://github.com/gcc-mirror/gcc.git, but only every 11-20
attempts.

I think this is a race condition somewhere, maybe in the threading code?

Dan

On Mon, 27 May 2024 at 21:45, Csaba Ráduly via Cygwin  wrote:
>
> On 26/05/2024 14:03, Adam Dinwoodie via Cygwin wrote:
> > On Sun, 26 May 2024 at 05:10, David Dyck via Cygwin wrote:
> >> I upgraded to the most recent git and I get the following error
> >> (  stable2.45.1-1x86_648597 KiB2024-05-25 18:58 )
> >>
> >> $ git clone -v https://github.com/lxml/lxml.git
> >> Cloning into 'lxml'...
> >> POST git-upload-pack (175 bytes)
> >> POST git-upload-pack (gzip 8652 to 4281 bytes)
> >> remote: Enumerating objects: 33933, done.
> >> remote: Counting objects: 100% (3778/3778), done.
> >> remote: Compressing objects: 100% (1322/1322), done.
> >> remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
> >> 30155
> >> Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done.
> >> fatal: fetch-pack: invalid index-pack output
> >>
> >> when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32
> >> I was able to get the repository download
> >>
> >> $ git clone -v https://github.com/lxml/lxml.git
> >> Cloning into 'lxml'...
> >> POST git-upload-pack (175 bytes)
> >> POST git-upload-pack (gzip 8652 to 4281 bytes)
> >> remote: Enumerating objects: 33933, done.
> >> remote: Counting objects: 100% (3778/3778), done.
> >> remote: Compressing objects: 100% (1322/1322), done.
> >> remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
> >> 30155
> >> Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done.
> >> Resolving deltas: 100% (16518/16518), done.
> > Thanks for the report. This is working fine for me locally.
>
>  Me too 
>
> $ git --version
> git version 2.45.1
> $ git clone -v https://github.com/lxml/lxml.git
> Cloning into 'lxml'...
> POST git-upload-pack (175 bytes)
> POST git-upload-pack (gzip 8652 to 4282 bytes)
> remote: Enumerating objects: 33941, done.
> remote: Counting objects: 100% (3786/3786), done.
> remote: Compressing objects: 100% (1327/1327), done.
> remote: Total 33941 (delta 2361), reused 3474 (delta 2244), pack-reused
> 30155
> Receiving objects: 100% (33941/33941), 20.20 MiB | 13.19 MiB/s, done.
> Resolving deltas: 100% (16523/16523), done.
>
> Csaba
>
> --
> Life is complex, with real and imaginary parts.
>
>
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[David Dyck via Cygwin]

Thank you for your ideas!

I have made no changes but can't reproduce the issue today
both with a very short path of /usr/bin and the original path
I tried with VPN off or on
I would be happy to try a few other experiments - but I don't even need the
workaround of reverting to an older git


$ which git
/usr/bin/git

$ git --version
git version 2.45.1

OPATH="$PATH"
PATH="/usr/bin"
git clone -v https://github.com/lxml/lxml.git

mv lxml lxml-
PATH="$OPATH"
git clone -v https://github.com/lxml/lxml.git

while rm -rf lxml && time git clone -v https://github.com/lxml/lxml.git  ;
do date ; done

at the moment the above loop runs hundreds of times without errors

On Mon, May 27, 2024 at 1:31 PM Adam Dinwoodie  wrote:

>
>
> I've just set up a test sandbox with the same set of Cygwin
> applications installed, and I'm still not able to replicate this
> failure, which is going to make it difficult to work out what's going
> wrong for you!
>
> I note your Cygwin PATH has several entries before /bin, including a
> ~/bin that apparently contains a perl executable; can you see if you
> can reproduce the problem with a clean PATH?
>
> In any case, I'm having to conclude the issue is something odd about
> your environment that doesn't seem to be affecting most people.
> Working out what's going wrong will probably require isolating what
> difference is relevant here. I think there's two obvious routes to
> doing that: you can work out what's odd about your environment (maybe
> use Windows Sandbox, given you're running Windows Enterprise? I've
> attached a .wsb file that should give you a starting point for setting
> up test environments, based on your cygcheck.out), or you can work out
> what's changed in Git between 2.42.0 and 2.45.1, which will probably
> mean building and bisecting Git yourself; once we know what change is
> the culprit, that'll make it much easier to work out what's going
> wrong.
>
> If it'd be useful, I can provide some test builds of Git to help
> narrow down where the problem is, but if you can do the builds
> yourself, that'll be a lot quicker than trying to do a binary chop by
> email…
>

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

On Fri, 24 May 2024 19:29:43 -0700 (PDT)
Jeremy Drake wrote:
> On Fri, 24 May 2024, Jeremy Drake wrote:
> 
> > On Fri, 24 May 2024, Jeremy Drake wrote:
> >
> > > Looking at !address, it seems Windows put the PEB, TEBs, and stacks in the
> > > area where the cygheap should be.  Way to go, ASLR :P
> >
> > I think the fix for this would be to add -Wl,--disable-high-entropy-va to
> > ldh_LDFLAGS, as was done for strace and cygcheck at least.  I used peflags
> > -d0 /usr/bin/ldh.exe and I'm not seeing a hang after that.
> 
> Sorry, that was peflags -e0 not -d0 (dynamicbase is still on):
> $ peflags -v /usr/bin/ldh.exe
> /usr/bin/ldh.exe:
> coff(0x0226[+executable_image,+line_nums_stripped,+bigaddr,+sepdbg])
> pe(0x0140[+dynamicbase,+nxcompat])

You are right!

It seems that VirtualAlloc() in cygheap_init() in mm/cygheap.cc
fails when the address range which cygwin uses is occupied due to
high-entropy-va in ldh.exe.

Thanks for the analysis.

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

Hi Jeremy,

On Tue, 28 May 2024 10:58:00 +0900
Takashi Yano wrote:
> On Fri, 24 May 2024 19:29:43 -0700 (PDT)
> Jeremy Drake wrote:
> > On Fri, 24 May 2024, Jeremy Drake wrote:
> > 
> > > On Fri, 24 May 2024, Jeremy Drake wrote:
> > >
> > > > Looking at !address, it seems Windows put the PEB, TEBs, and stacks in 
> > > > the
> > > > area where the cygheap should be.  Way to go, ASLR :P
> > >
> > > I think the fix for this would be to add -Wl,--disable-high-entropy-va to
> > > ldh_LDFLAGS, as was done for strace and cygcheck at least.  I used peflags
> > > -d0 /usr/bin/ldh.exe and I'm not seeing a hang after that.
> > 
> > Sorry, that was peflags -e0 not -d0 (dynamicbase is still on):
> > $ peflags -v /usr/bin/ldh.exe
> > /usr/bin/ldh.exe:
> > coff(0x0226[+executable_image,+line_nums_stripped,+bigaddr,+sepdbg])
> > pe(0x0140[+dynamicbase,+nxcompat])
> 
> You are right!
> 
> It seems that VirtualAlloc() in cygheap_init() in mm/cygheap.cc
> fails when the address range which cygwin uses is occupied due to
> high-entropy-va in ldh.exe.
> 
> Thanks for the analysis.

Would you make a patch for that?

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple