from:"cygwin"


On 27/05/2024 16:14, Ken Brown via Cygwin wrote:

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.


Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might 
be an unintended consequence of the dumper changes I made in 3.5.0.



0  0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#1  0x7ffd527f6367 in break_here () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472
#2  0x7ffd52810349 in try_to_debug () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597
#3  exception::handle (e=0x28bc6f0, frame=, in=0x28bc200, 
dispatch=)
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810
#4  0x7ffd871b49ff in ntdll!.chkstk () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x7ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x7ffd871b39ee in ntdll!KiUserExceptionDispatcher () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x7ffd5291bdd4 in init_cygheap::find_tls (this=0x8, sig=20, 
issig_wait=@0x28bca3f: false)


The important thing in this backtrace is that an exception is occurring 
in find_tls, not that we break into the debugging while handling it 
(rather than rethrowing the exception to let the debugger handle it, 
which is maybe what should happen? and did in previous versions of Cygwin??)



--
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: ftp.acc.umu.se domain move


On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:


Hi!

The contact information, and preferably the host/mirror name, for the
mirror provided by Academic Computer Club (ACC) needs to be changed as
ACC is moving to a new domain. To verify the validity of this
message, point a web browser towards https://ftp.acc.umu.se/ and
notice that the top-level redirects to https://mirror.accum.se/. Also
notice the text about acc.umu.se at the top of the page.

Background: Umeå University has decided that non-official services are
no longer allowed to exist as a sub domain to umu.se. As a consequence
of this we are moving all services from the acc.umu.se domain.

Contact email:

Changes from ftp-...@acc.umu.se to ftp-...@accum.se. The old email
address will stop working sometime in the future.

File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.

Thanks for providing a cygwin mirror.


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

[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)

2024-05-30 Thread Brian Inglis via Cygwin-apps


On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote:

On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:
Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


 "LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.


I found github/nexB/license-expression Python package to do SPDX licence checks 
with current data, developed by the same team doing SPDX-toolkit for SPDX, 
working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

log at:

https://github.com/cygwin/scallywag/actions/runs/9293093201

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>

--
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#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package 
build control script definitions

inherit python-wheel

NAME=python-license-expression
VERSION=30.3.0
RELEASE=1

BASE=${NAME#python-}

CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."

ARCH=noarch

LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"

DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"

#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression

Usage: spdx-license-expression.py 

Author: Brian Inglis 
"""

from license_expression import get_spdx_licensing
import sys

def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
  file=sys.stderr)
return 1

licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
#   original_expression='... and MIT and GPL-2.0+',
#   normalized_expression=None,
#   errors=['Unknown license key(s): ...'],
#   invalid_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
i

Fwd: newer version of mingw64-*-win-iconv ?

2024-05-30 Thread Brian Inglis via Cygwin-apps


On 2024-05-29 02:53, Bruno Haible via Cygwin wrote:

Brian Inglis wrote:

Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
and   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv



Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?


v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs
need a working ASCII encoding, which is fixed in v0.0.8.


NMU updates of the above packages would be appreciated, based on those
mingw...-win-iconv playground branch updates, if someone could help, please?

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

Re: newer version of mingw64-*-win-iconv ?

2024-05-30 Thread Brian Inglis via Cygwin


On 2024-05-29 02:53, Bruno Haible via Cygwin wrote:

Brian Inglis wrote:

Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
and   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv



Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?


v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs
need a working ASCII encoding, which is fixed in v0.0.8.


NMU updates of the above packages would be appreciated, based on those
mingw...-win-iconv playground branch updates, if someone could help, please?

--
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: SRW locks

Noel Grandin wrote:
> > Still: Does ReleaseSRWLockExclusive notify other threads?
> > 
> 
> Of course? How else would a lock work, it must release other waiters?
> 
> It might not be a fair lock though, which is not a problem for this 
> situation, which does not require fair locking.
> 
> 
> > Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano 
> > mentioned,
> > how would you make it fit into a pthread_once_t that is defined as
> >struct { pthread_mutex_t mutex; int state; }
> > ?
> 
> Something like:
> 
> struct once {
> union {
>pthread_mutex_t old_mutex_field_for_size_compatibility;
>SRWLOCK lock = SRWLOCK_INIT;
>  };
>  int state;
> };

Reading [1], it seems that this might indeed work, and be faster than code
that uses CRITICAL_SECTIONs.

Still, something to watch out is this bug [2].

All in all, I would say that every such change ought to be tested with a
nontrivial test program that performs several thousands of rounds.

Bruno

[1] https://marabos.nl/atomics/os-primitives.html
[2] 
https://old.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/




-- 
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches:
> With v3 patch:
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>   /* Sign bit of once_control->state is used as done flag */
>   if (once_control->state & INT_MIN)
> return 0;
> 
>   /* The type of _control->state is int *, which is compatible with
>  LONG * (the type of the first argument of InterlockedIncrement()). */
>   InterlockedIncrement (_control->state);
>   pthread_mutex_lock (_control->mutex);
>   if (!(once_control->state & INT_MIN))
> {
>   init_routine ();
>   InterlockedOr (_control->state, INT_MIN);
> }
>   pthread_mutex_unlock (_control->mutex);
>   if (InterlockedDecrement (_control->state) == INT_MIN)
> pthread_mutex_destroy (_control->mutex);
>   return 0;
> }

Looks good to me.

If it passes 10 or 100 runs of my test program from
<https://cygwin.com/pipermail/cygwin/2024-May/255987.html>,
I would say, it's good.

Thanks!

Bruno




-- 
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: Use Cygwin gcc or clang to build with ucrt?


On 22/05/2024 00:30, Dan Shelton via Cygwin wrote:

Hello!

Can Cygwin gcc or clang be used to use ucrt instead of cygwin.dll/mingw.dll?


We provide a cross-compiler targeting the Win32 API, but this only 
support  msvcrt currently.


[1] https://cygwin.com/faq.html#faq.programming.win32-no-cygwin


--
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: LD_PRELOAD for Win32?


On 25/05/2024 22:55, Martin Wege via Cygwin wrote:

Hello,

Does Cygwin or Win32 have something like LD_PRELOAD, so I can
override/substitute functions in a DLL or EXE, like it is common for
UNIX/Linux ELF shared libraries?


This is not generally available on Win32, due to limitations of the PE 
file format.


(basically, the import table lists symbols which are imported, and where 
they are imported from, so the module (shared library or executable) 
which provides a given symbol is determined when the module is *linked*, 
not when it is loaded.



However, when googling "cygwin LD_PRELOAD" (which surely you must have 
done before asking this question?) I discover that there's some voodoo 
in the cygwin DLL (hookapi.cc) which claims to do something like that, 
but it seems (i) this requires the preloaded DLL to explicitly hook 
functions it's overriding, and (ii) maybe only works on functions 
imported by the running executable.


It would be nice to have some documentation for that, and/or a simple 
example which could serve as a testcase.


--
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

2024-05-30 Thread Noel Grandin via Cygwin





On 5/30/2024 11:15 AM, Bruno Haible wrote:


Still: Does ReleaseSRWLockExclusive notify other threads?



Of course? How else would a lock work, it must release other waiters?

It might not be a fair lock though, which is not a problem for this situation, 
which does not require fair locking.



Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano mentioned,
how would you make it fit into a pthread_once_t that is defined as
   struct { pthread_mutex_t mutex; int state; }
?


Something like:

struct once {
   union {
  pthread_mutex_t old_mutex_field_for_size_compatibility;
  SRWLOCK lock = SRWLOCK_INIT;
};
int state;
};

Regards, Noel Grandin

--
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches:
>  int
>  pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
>  {
> -  // already done ?
> -  if (once_control->state)
> +  /* Sign bit of once_control->state is used as done flag */
> +  if (once_control->state & INT_MIN)
>  return 0;
>  
> +  /* The type of _control->state is int *, which is compatible with
> + LONG * (the type of the first argument of InterlockedIncrement()). */
> +  InterlockedIncrement (_control->state);
>pthread_mutex_lock (_control->mutex);
> -  /* Here we must set a cancellation handler to unlock the mutex if needed */
> -  /* but a cancellation handler is not the right thing. We need this in the 
> thread
> -   *cleanup routine. Assumption: a thread can only be in one pthread_once 
> routine
> -   *at a time. Stote a mutex_t *in the pthread_structure. if that's non null 
> unlock
> -   *on pthread_exit ();
> -   */

Sorry, in a unified diff form this is unreadable. One needs to look at the
entire function. A context diff would have been better. So:

int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
  /* Sign bit of once_control->state is used as done flag */
  if (once_control->state & INT_MIN)
return 0;

  /* The type of _control->state is int *, which is compatible with
 LONG * (the type of the first argument of InterlockedIncrement()). */
  InterlockedIncrement (_control->state);
  pthread_mutex_lock (_control->mutex);
  if (!(once_control->state & INT_MIN))
{
  init_routine ();
  once_control->state |= INT_MIN;
}
  pthread_mutex_unlock (_control->mutex);
  if (InterlockedDecrement (_control->state) == INT_MIN)
pthread_mutex_destroy (_control->mutex);
  return 0;
}

1) The overall logic seems right (using bit 31 of the state word as a
'done' bit), and the last thread that used the mutex destroys it.

2) However, the 'state' field is not volatile, and therefore the memory
model does not guarantee that an assignment

 once_control->state |= INT_MIN;

done in one thread has an effect on the values seen by other threads
that do

 if (once_control->state & INT_MIN)

As long as there is no synchronization between the two CPUs that execute
the two threads, one CPU may indefinitely see the old value of
once_control->state, while the other CPU's new value is not being
"broadcasted" to all CPUs.

3) Also, as noted by Noel Grandin, there is a race: If one thread does

 once_control->state |= INT_MIN;

while another thread does

 InterlockedIncrement (_control->state);
or
 InterlockedDecrement (_control->state)

the result can be that the increment or decrement is nullified. If it's
an increment that gets nullified, the pthread_mutex_destroy occurs too
early, with fatal consequences. If it's a decrement that get nullified,
the pthread_mutex_destroy never happens, and there is therefore a resource
leak.

4) Does the test program that I posted in
<https://cygwin.com/pipermail/cygwin/2024-May/255987.html> now pass?
Notes:
  - You should set
  #define ENABLE_DEBUGGING 0
because with the debugging output, it nearly always succeeds.
  - You should run it 10 times in a row, not just once. It may well
succeed 9 out of 10 times and fail 1 out of 10 times.

Bruno




-- 
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote:
> > SRW locks are spin-locks. Since they are only pointer-sized,
> > ReleaseSRWLockExclusive cannot notify other threads — unlike 
> > CRITICAL_SECTION.
> > Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
> > held.
> > 
> 
> No, they only spin briefly, before calling into the OS to sleep - see the 
> article about their internals here:
> 
> https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c#slim-readerwriter-lock

Still: Does ReleaseSRWLockExclusive notify other threads?

> Alternatively, Windows already has an API for init-once i.e.
>
> https://learn.microsoft.com/en-us/windows/win32/sync/one-time-initialization

Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano mentioned,
how would you make it fit into a pthread_once_t that is defined as
  struct { pthread_mutex_t mutex; int state; }
?

Bruno




-- 
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

2024-05-30 Thread Noel Grandin via Cygwin




On 5/30/2024 10:47 AM, Bruno Haible wrote:


SRW locks are spin-locks. Since they are only pointer-sized,
ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION.
Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
held.



No, they only spin briefly, before calling into the OS to sleep - see the 
article about their internals here:

https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c#slim-readerwriter-lock


Alternatively, Windows already has an API for init-once i.e.
  https://learn.microsoft.com/en-us/windows/win32/sync/one-time-initialization

--
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote in cygwin-patches:
> Pardon my ignorance, but why not rather use the Windows SRWLock functionality?
> https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks
> 
> SRW locks are very fast, only require a single pointer-sized storage area, 
> can be statically initialised, and do not 
> need to be destroyed, so there is no possibibilty of memory leakage.
> 
> Then the implementation simply becomes
> 
> int pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>  AcquireSRWLockExclusive(once_control->lock);
>  if (!once_control->state)
>  {
>  init_routine()
>  once_control->state = 1;
>  }
>  ReleaseSRWLockExclusive(once_control->lock);
> }

SRW locks are spin-locks. Since they are only pointer-sized,
ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION.
Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
held.

But busy-looping is a bad practice for pthread_once. In the case,
for example, that the init_routine reads a multi-megabyte data
structure into memory and parses it, the other threads that wait
on the result of this operation would by busy-looping, eating
full CPU time.

Bruno




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

Request: please update to coreutils >=9.1

2024-05-30 Thread Lluís Batlle i Rossell via Cygwin

Hello,

there are 3 coreutils versions in cygwin: 8.26, 8.32 and 9.0.

8.32 has a big bug on "cp" that leaks file descriptors. Copying many
files it dies with Too many open files.

9.0 has a bug that makes any chmod fail silently if it is applied to
symlink.

Both bugs have the impact that we are stuck to coreutils 8.26 for our
build scripts, that use 'cp -R' and 'chmod -R' and would otherwise fail.

Can someone update to a newer coreutils? 9.1 or later.

(I'm not subscribed to the list, please keep me in Cc)

Thank you,
Lluís


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

[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)

2024-05-29 Thread Brian Inglis via Cygwin-apps


On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote:

On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:


Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.


Thought not, but after recent reminder, not so sure now ;^>

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


There have been changes in how to specify exceptions using WITH.

It would also be useful if it could also be taught to accept 'LicenseRef-.*' 
identifiers.


Ditto ExceptionRef-.* but that and LicenseRef-.* do not seem to be allowed by 
PEP 639, as they unrealistically expect projects to change existing licences, 
whereas we have to deal with historical reality like Fedora!


So, suggestions on a different module to use, or patches to make this work 
better, or cogent arguments why we should just remove this validation are all 
welcome.


How about if we delegate licence validation to cygport, as someone recently 
offered, or as currently done in calm, with current Cygwin python - add licence 
validation hint to src hint - if not there, calm does it as now?


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


 "LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.


Cheers!


I found github/nexB/license-expression Python package to do SPDX licence checks 
with current data, developed by the same team doing SPDX-toolkit for SPDX, 
working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

log at:

https://github.com/cygwin/scallywag/actions/runs/9293093201

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>

The approach may also be adaptable to calm if you can get 
python-license-expression 30.3.0 installed on the server(s), and kept updated:


https://repology.org/project/python:license-expression/versions

and Cygwin should soon be added there hopefully! ;^>

--
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#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package 
build control script definitions

inherit python-wheel

NAME=python-license-expression
VERS

Updated: w32api-{headers,runtime} mingw64-{headers,runtime,winpthreads} 12.0.0-1

2024-05-29 Thread Jonathan Yong via Cygwin-announce




Important Notice:
Upstream mingw-w64 12.0.0 is now using UCRT as the default C Runtime for 
better C99 printf and math.h floating point performance, but it can 
still be configured to continue using MSVCRT.


Switching C Runtimes requires all binaries to be rebuilt from source, 
including all compiler support libraries.


Packages for Cygwin (mingw64-{headers,runtime,winpthreads} packages) are 
built with MSVCRT as the C Runtime provider for compatibility with 
existing Cygwin provided mingw-w64 cross compiled binaries and libraries.


This means it is still safe to use existing Cygwin mingw64-* packages 
with the latest Cygwin mingw-w64 cross compiler, since this new release 
continues to use MSVCRT, similar to the previous releases.


C libraries and binaries built by mingw-w64 toolchains that target UCRT 
may not be compatible if C standard library API handles such as handles 
from open(), fopen(), free() and etc, are passed through the library 
boundaries.


C++ libraries built by mingw-w64 toolchains that target UCRT are 
unlikely to be compatible if C++ standard library APIs are utilized 
across library boundaries.


Win32 API handles such as those used by CreateFileW() or 
WaitForSingleObject() are unaffected.


Purely Cygwin applications using POSIX/UNIX APIs are unaffected by the 
change.


Notable changes:
* C++ overloads for _strdate_s and _strtime_s, _makepath_s, wcsncat_s.
* gdtoa updated against netlib.org, up to January 2023.
* genlib tool removed in favor of llvm-dlltool, created by the same author.
* Make it possible to use winpthreads with MSVC.
* Updated wine header imports.
* Many other new win32 APIs.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.

--
     *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
<https://cygwin.com/mailman/options/cygwin-announce>, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
<https://sourceware.org/lists.html#unsubscribe>.

Re: Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

2024-05-29 Thread Bill Stewart via Cygwin

On Tue, May 28, 2024 at 9:36 PM Dan Shelton wrote:


> Does anyone know how to run Windows explorer.exe with Cygwin
> /bin/newgrp, so all new files created by explorer.exe use that new
> primary group, and all programs launched by explorer.exe use that same
> primary group?
>

As I understand it, Explorer always starts unelevated as the current user.
This is by design for security reasons.

Bill

-- 
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: WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

2024-05-29 Thread Bill Stewart via Cygwin

On Tue, May 28, 2024 at 8:29 PM Dan Shelton wrote:

Just a couple of ideas:
> - Native Windows doesn't have an easy way to list group memberships
> for the current user, so a WinSG -l to list available groups would be
> good
>

Maybe you weren't aware of it - 'whoami /groups'


> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
>

Not IMHO.


> - Native Windows utilities use /? for help, not --help
>

This is really only a loosely followed convention and not all Windows tools
follow it. (Example: Windows PowerShell cmdlet parameters use "-", not "/".)

Bill

-- 
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: multithreading broken in Cygwin 3.5.3

Takashi Yano wrote:
> > My workaround implementation of pthread_once (in gnulib) looks like this:
> > 
> >   /* This would be the code, for
> >typedef struct
> >  {
> >pthread_mutex_t mutex;
> >_Atomic unsigned int num_threads;
> >_Atomic unsigned int done;
> >  }
> >pthread_once_t;
> >*/
> >   if (once_control->done == 0)
> > {
> >   once_control->num_threads += 1;
> >   pthread_mutex_lock (_control->mutex);
> >   if (once_control->done == 0)
> > {
> >   (*initfunction) ();
> >   once_control->done = 1;
> > }
> >   pthread_mutex_unlock (_control->mutex);
> >   if ((once_control->num_threads -= 1) == 0)
> > pthread_mutex_destroy (_control->mutex);
> > }
> > 
> > It makes sure that
> >   - The last thread that had been dealing with the mutex deletes
> > the mutex.
> >   - Once the mutex is deleted, is it never again accessed. The
> > entry test of the 'done' boolean ensures this.
> 
> Thanks for the advice.
> 
> The problem is that we cannot change the type of pthread_once_t
> for binary compatibility. My patch stops to use
> pthread_mutex_t mutex in pthread_once_t however it cannot be
> deleted despite it is not used at all.

This problem can be solved, by using
  - the upper 31 bits of 'state' as 'num_threads' and
  - the lowest bit of 'state' as 'done' bit.

I did this in gnulib:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/pthread-once.c;h=069e77e3f3fc2a6e6564f73ba1a3f86ddf9ba531;hb=HEAD#l41
and I have tested it with the test program 'test-pthread-once2' that
I mentioned in my original report.

You can take this code, since I licensed it under LGPLv2+. You can
also surely simplify it, since you are an expert with the Interlocked*
atomic operations (whereas I only wanted to use the GCC built-in
__sync* atomics).

Bruno




-- 
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: [PATCH] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches:
> To avoid race issues, pthread::once() uses pthread_mutex. This caused
> the handle leak which was fixed by the commit 2c5433e5da82. However,
> this fix introduced another race issue, i.e., the mutex may be used
> after it is destroyed. With this patch, do not use pthread_mutex in
> pthread::once() to avoid both issues. Instead, InterlockedExchage()
> is used.

This patch is bogus as well, because it allows one thread to return
from a pthread_once call while the other thread is currently
executing the init_routine and not yet done with it.

> +  if (!InterlockedExchange (_control->state, 1))
> +init_routine ();
> return 0;
> }

There is no code after the init_routine () call here. This means
that other threads are not notified when the init_routine () call
is complete. Therefore this implementation *cannot* be correct.

See: Assume thread1 and thread2 call pthread_once on the same
once_control.

thread1  thread2
---  ---

 enters pthread_once   enters pthread_once

 sets state to 1

   sees that state == 1

   returns from pthread_once

   executes code that assumes
   init_routine has completed

 starts executing
 init_routine

 finished executing
 init_routine

 returns from pthread_once

Bruno




-- 
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: multithreading broken in Cygwin 3.5.3

2024-05-29 Thread Takashi Yano via Cygwin

On Wed, 29 May 2024 12:26:31 +0200
Bruno Haible wrote:
> Takashi Yano wrote:
> > As you mentioned in private mail to me, this seems to be a regression of
> > pthread::once() introduced by
> > commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.
> > 
> > I'll submit a patch for that issue shortly.
> 
> My workaround implementation of pthread_once (in gnulib) looks like this:
> 
>   /* This would be the code, for
>typedef struct
>  {
>pthread_mutex_t mutex;
>_Atomic unsigned int num_threads;
>_Atomic unsigned int done;
>  }
>pthread_once_t;
>*/
>   if (once_control->done == 0)
> {
>   once_control->num_threads += 1;
>   pthread_mutex_lock (_control->mutex);
>   if (once_control->done == 0)
> {
>   (*initfunction) ();
>   once_control->done = 1;
> }
>   pthread_mutex_unlock (_control->mutex);
>   if ((once_control->num_threads -= 1) == 0)
> pthread_mutex_destroy (_control->mutex);
> }
> 
> It makes sure that
>   - The last thread that had been dealing with the mutex deletes
> the mutex.
>   - Once the mutex is deleted, is it never again accessed. The
> entry test of the 'done' boolean ensures this.

Thanks for the advice.

The problem is that we cannot change the type of pthread_once_t
for binary compatibility. My patch stops to use
pthread_mutex_t mutex in pthread_once_t however it cannot be
deleted despite it is not used at all.

-- 
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: multithreading broken in Cygwin 3.5.3

Takashi Yano wrote:
> As you mentioned in private mail to me, this seems to be a regression of
> pthread::once() introduced by
> commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.
> 
> I'll submit a patch for that issue shortly.

My workaround implementation of pthread_once (in gnulib) looks like this:

  /* This would be the code, for
   typedef struct
 {
   pthread_mutex_t mutex;
   _Atomic unsigned int num_threads;
   _Atomic unsigned int done;
 }
   pthread_once_t;
   */
  if (once_control->done == 0)
{
  once_control->num_threads += 1;
  pthread_mutex_lock (_control->mutex);
  if (once_control->done == 0)
{
  (*initfunction) ();
  once_control->done = 1;
}
  pthread_mutex_unlock (_control->mutex);
  if ((once_control->num_threads -= 1) == 0)
pthread_mutex_destroy (_control->mutex);
}

It makes sure that
  - The last thread that had been dealing with the mutex deletes
the mutex.
  - Once the mutex is deleted, is it never again accessed. The
entry test of the 'done' boolean ensures this.

Bruno




-- 
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: multithreading broken in Cygwin 3.5.3

2024-05-29 Thread Takashi Yano via Cygwin

On Thu, 23 May 2024 20:09:09 +0200
Bruno Haible wrote:
> In Cygwin 3.5.3, on different machines, I see 3 Gnulib tests failing by
> timeout that worked perfectly fine in Cygwin 3.4.6 and older:
>   FAIL: test-call_once2.exe
>   FAIL: test-lock.exe
>   FAIL: test-pthread-once2.exe
> 
> Find here attached a simplified version of test-pthread-once2.c.
> Compile and run:
>   $ x86_64-pc-cygwin-gcc -Wall foo.c
>   $ ./a
> 
> Expected behaviour: Termination within 1 minute.
> Actual behaviour:   Terminates by timeout after 10 minutes.
> 
> When I change
>   #define ENABLE_DEBUGGING 0
> to
>   #define ENABLE_DEBUGGING 1
> the test does lots of output and terminates within 20 seconds.
> Therefore I can't really tell where the problem comes from.
> But I do see some changes in
>   $ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/cygwin/thread.cc
>   $ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/testsuite/winsup.api/pthread

Thanks for the report.

As you mentioned in private mail to me, this seems to be a regression of
pthread::once() introduced by
commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.

I'll submit a patch for that issue shortly.

-- 
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: newer version of mingw64-*-win-iconv ?

Brian Inglis wrote:
> Ran playground local and CI builds of these packages at v0.0.8 successfully:
> 
>   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
>   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

and   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv

Thanks!

> Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs
need a working ASCII encoding, which is fixed in v0.0.8.

> [Are we really still building 32 bit mingw packages when we dropped support 
> of 
> 32 bit Windows << 1%?

I regularly build all my packages on 32-bit and 64-bit mingw. Also, I know that
GNU Emacs wants binaries that work on Windows XP, and that means 32-bit 
binaries.

> Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in 
> February.

Games are a particular niche of the PC market, isn't it? Hardware that consumes
lots of power and is loud, reflective displays, mostly proprietary software?

Bruno

-- 
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: newer version of mingw64-*-win-iconv ?

2024-05-29 Thread Brian Inglis via Cygwin-apps


On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if required, and 
do NMU builds and deploys of these?


[Are we really still building 32 bit mingw packages when we dropped support of 
32 bit Windows << 1%?

Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in 
February.
Surveys don't even bother to report that share nowadays!]

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

Re: newer version of mingw64-*-win-iconv ?

2024-05-29 Thread Brian Inglis via Cygwin


On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if required, and 
do NMU builds and deploys of these?


[Are we really still building 32 bit mingw packages when we dropped support of 
32 bit Windows << 1%?

Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in 
February.
Surveys don't even bother to report that share nowadays!]

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

Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

2024-05-28 Thread Dan Shelton via Cygwin

Hello!

Does anyone know how to run Windows explorer.exe with Cygwin
/bin/newgrp, so all new files created by explorer.exe use that new
primary group, and all programs launched by explorer.exe use that same
primary group?

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

WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

2024-05-28 Thread Dan Shelton via Cygwin

On Tue, 28 May 2024 at 22:15, Cedric Blancher via Cygwin
 wrote:
>
> Good evening!
>
> For your consideration - we need FEEDBACK, please!
>
> New is support running it as service (sc start
> ms-nfs41-client-service), setgid()/newgrp support (with a new winsg
> utility to run Windows applications with different primary group),
> 32bit kernel support, ACL+UNC path (cd //host@port/path1/path2 work in
> bash and ksh93)+chgrp+nfs:// support, and the NFS server no longer
> needs the "insecure" export switch.

The WinSG utility is actually cool, because it can be used like a
normal Windows utility, and brings support for using multiple groups
to native Windows.

Just a couple of ideas:
- Native Windows doesn't have an easy way to list group memberships
for the current user, so a WinSG -l to list available groups would be
good
- WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
- PowerShell plugin would be cool
- Explorer Plugin to switch groups
- Native Windows utilities use /? for help, not --help

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

newer version of mingw64-*-win-iconv ?

2024-05-28 Thread Bruno Haible via Cygwin

Hi,

It would be useful if someone could rebuild the two packages
  https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
  https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].

Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.

Regards,

  Bruno

[1] https://github.com/win-iconv/win-iconv




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

Fwd: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

2024-05-28 Thread Cedric Blancher via Cygwin

Good evening!

For your consideration - we need FEEDBACK, please!

New is support running it as service (sc start
ms-nfs41-client-service), setgid()/newgrp support (with a new winsg
utility to run Windows applications with different primary group),
32bit kernel support, ACL+UNC path (cd //host@port/path1/path2 work in
bash and ksh93)+chgrp+nfs:// support, and the NFS server no longer
needs the "insecure" export switch.

Ced

-- Forwarded message -
From: Roland Mainz 
Date: Tue, 28 May 2024 at 19:17
Subject: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client
Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...
To: 


Hi!



I've created a set of test binaries for the NFSv4.1 filesystem client
driver for Windows 10/11, based on
https://github.com/kofemann/ms-nfs41-client (commit id
#0cb44281d376cd6aa0e43a402153405b7b32ddd8, git bundle in tarball), for
testing and feedback (download URL in "Download" section below).

Please send comments, bugs, test reports, complaints etc. to the
MailMan mailing list at
https://sourceforge.net/projects/ms-nfs41-client/lists/ms-nfs41-client-devel

# 1. What is this ?
NFSv4.1 client and filesystem driver for Windows 10/11

# 2. Features:
- Full NFSv4.1 protocol support
- idmapper (mapping usernames and uid/gid values between server and
client)
- Support for custom ports (NFSv4 defaults to TCP port 2049, this
client can use different ports per mount)
- Support for nfs://-URL
* Why ? nfs://-URLs are crossplatform, portable and Character-Encoding
  independent descriptions of NFSv4 server resources (exports).
- including custom ports and raw IPv6 addresses
- nfs://-URL conversion utility (/usr/bin/nfsurlconv) to convert
URLs, including non-ASCII/Unicode characters in mount path
- Support ssh forwarding, e.g. mounting NFSv4 filesystems via ssh
tunnel
- Support for long paths (up to 4096 bytes), no Windows MAXPATH limit
- Unicode support
- UNC paths
- IPv6 support in UNC paths
- /sbin/nfs_mount prints UNC paths in Win32+Cygwin formats
- Cygwin bash+ksh93 support UNC paths, e.g.
  cd //derfwnb4966@2049/nfs4/bigdisk/mysqldb4/
- IPv6 support
- IPv6 address within '[', ']'
  (will be converted to *.ipv6-literal.net)
- Windows ACLs
- Win32 C:\Windows\system32\icacls.exe
- Cygwin /usr/bin/setfacl+/usr/bin/getfacl
- Windows Explorer ACL dialog
- SFU/Cygwin support, including:
- uid/gid
- Cygwin symlinks
- Custom primary group support
- Supports primary group changes in the calling process/thread
  (via |SetTokenInformation(..., TokenPrimaryGroup,...)|), e.g.
  if the calling process/threads switches the primary group
  in its access token then the NFSv4.1 client will use that
  group as GID for file creation.
- newgrp(1)/sg(1)-style "winsg" utilty to run cmd.exe with
  different primary group, e.g.
  $ winsg [-] -g group [-c command | /C command] #
- Software compatibility:
- Any NFSv4.1 server (Linux, Solaris, Illumos, FreeBSD, nfs4j,
...)
- All tools from Cygwin/MinGW
- Visual Studio
- VMware Workstation (can use VMs hosted on NFSv4.1 filesystem)


# 3. Requirements:
- Windows 10 (32bit or 64bit) or Windows 11
- Cygwin:
- Cygwin versions:
- 64bit: >= 3.5.3 (or 3.6.x-devel)
- 32bit: >= 3.3.6
- Packages (required):
cygwin
cygwin-devel
cygrunsrv
cygutils
cygutils-extra
bash
bzip2
coreutils
getent
gdb
grep
hostname
less
libiconv
libiconv2
pax
pbzip2
procps-ng
sed
tar
time
util-linux
wget
- Packages (recommended):
libnfs (for /usr/bin/nfs-ls)
make
git
gcc-core
gcc-g++
clang
mingw64-i686-clang
mingw64-x86_64-clang
dos2unix
unzip


# 4. Download:
$ mkdir -p ~/download
$ cd ~/download
$ wget 
'http://www.nrubsig.org/people/gisburn/work/msnfs41client/releases/testing/msnfs41client_cygwin_binaries_20240528_12h15m_git0cb4428.tar.bz2'
$ openssl sha256
"msnfs41client_cygwin_binaries_20240528_12h15m_git0cb4428.tar.bz2"
SHA2-256(msnfs41client_cygwin_binaries_20240528_12h15m_git0cb4428.tar.bz2)=
e3d7adeef8b28161410bb7095036043aa587190488bf9247a00b881c19dbcc0d


# 5. Installation (as "Administrator"):
$ (cd / && tar -xf
~/download/msnfs41client_cygwin_binaries_20240528_12h15m_git0cb4428.tar.bz2
)
$ /sbin/msnfs41client install



# 6. Deinstallation:
$ (set -o xtrace ; cd / && tar -tf
~/download/msnfs41client_cygwin_binaries_20240528_12h15m_git0cb4428.tar.bz2
| while read i ; do [[ -f "$i" ]] && rm "$i" ; done)



# 7. Usage:
# Option a)
# * Start NFSv4 client daemon as Windows service (requires
# "Adminstrator" account):

$ sc start m

Re: [PATCH v1] Cygwin: disable high-entropy VA for ldh

2024-05-28 Thread Jeremy Drake via Cygwin-patches

On Tue, 28 May 2024, Jeremy Drake via Cygwin-patches wrote:

> @@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll

Oops, I accidentally generated this patch against msys2-3.5.3 branch,
rather than cygwin master like the last one.  The only difference is the
line numbers above, and it does apply cleanly to cygwin master, so I won't
send another version unless I'm requested to.

[PATCH v1] Cygwin: disable high-entropy VA for ldh

2024-05-28 Thread Jeremy Drake via Cygwin-patches

If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
up loading the Cygwin DLL dynamically, much like cygcheck or strace.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
Signed-off-by: Jeremy Drake 
---
 winsup/utils/mingw/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/winsup/utils/mingw/Makefile.am b/winsup/utils/mingw/Makefile.am
index b89d89490a..07b9f928d4 100644
--- a/winsup/utils/mingw/Makefile.am
+++ b/winsup/utils/mingw/Makefile.am
@@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
 cygwin_console_helper_SOURCES = cygwin-console-helper.cc

 ldh_SOURCES = ldh.cc
+ldh_LDFLAGS = ${AM_LDFLAGS} -Wl,--disable-high-entropy-va

 strace_SOURCES = \
path.cc \
-- 
2.45.1.windows.1

Re: [PATCH] Cygwin: disable high-entropy VA for ldh

2024-05-28 Thread Jeremy Drake via Cygwin-patches

On Tue, 28 May 2024, Takashi Yano wrote:

> On Mon, 27 May 2024 22:36:07 -0700 (PDT)
> Jeremy Drake wrote:
> > If ldd is run against a DLL or EXE which links to the Cygwin DLL, ldh
> > will end up loading the Cygwin DLL dynamically, much like cygcheck or
> > strace.
>
> IIUC, ldh is not used for EXE.

You are correct.  I didn't read ldd.cc.  I'll send the patch again with
"or EXE" removed from the commit message.

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

2024-05-28 Thread ASSI via Cygwin

Adam Dinwoodie via Cygwin writes:
> Thanks for the report. This is working fine for me locally. Can you
> please upgrade, check the problem is still recurring, and provide the
> output from `cygcheck -srv >cygcheck.out`?

This issue is most likely an upstream regression that was either
introduced among some security fixes that were less widely checked due
to disclosure embargo in 2.45 or else an earlier regression in 2.42 that
disabled the use of some deprecated OpenSSL3 functions (and missing one
or two instances of code that still need the functionality in certain
cases).

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

2024-05-28 Thread Brian Inglis via Cygwin


On 2024-05-27 16:10, Dan Shelton via Cygwin wrote:

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?


SO suggestions are other git versions in the path, bad downstream proxy cache, 
slow or invasive network security appliance, which may be bypassed with ssh or 
VPN URIs, low resource limits in containers, which can be relieved by bumping 
resources or reducing sizes:


git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

or huge repos which can be alleviated by a shallow clone --depth=1.

--
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: calm: SPDX licence list data update please

2024-05-28 Thread Brian Inglis via Cygwin-apps


On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:


Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.


Thought not, but after recent reminder, not so sure now ;^>

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


There have been changes in how to specify exceptions using WITH.

It would also be useful if it could also be taught to accept 'LicenseRef-.*' 
identifiers.


Ditto ExceptionRef-.* but that and LicenseRef-.* do not seem to be allowed by 
PEP 639, as they unrealistically expect projects to change existing licences, 
whereas we have to deal with historical reality like Fedora!


So, suggestions on a different module to use, or patches to make this work 
better, or cogent arguments why we should just remove this validation are all 
welcome.


How about if we delegate licence validation to cygport, as someone recently 
offered, or as currently done in calm, with current Cygwin python - add licence 
validation hint to src hint - if not there, calm does it as now?


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


"LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.


Cheers!

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

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

2024-05-28 Thread Lemures Lemniscati via Cygwin

On Mon, 27 May 2024 11:14:29 -0400, 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?

(1) Keeping asymptote 2.88-1, I tested with packages rolled back:

PackageVersionStatus
cygwin 3.4.10-1   OK
cygwin-debuginfo   3.4.10-1   OK
dash   0.5.12-2   OK
libunistring-debuginfo 1.1-1  OK
libunistring-devel 1.1-1  OK
libunistring5  1.1-1  OK
tar1.35-1 OK

uname -svrmo 
CYGWIN_NT-10.0-22631 3.4.10-1.x86_64 2023-11-29 12:12 UTC x86_64 Cygwin

Then, `HOME=/tmp asy -vv -f pdf test` hanged.
But, asy invoked by gdb did not hang...

(2) asymptote 2.85-1 with same packages
(ignoring warning about texlive 2024):

Then, `HOME=/tmp asy -vv -f pdf test` hanged.
But, asy invoked by gdb did not hang...

(3) asymptote 2.85-1 with packages (latest except asymptote)
(ignoring warning about texlive 2024):

PackageVersion  Status
asymptote  2.85-1 OK
cygwin 3.5.3-1OK
cygwin-debuginfo   3.5.3-1OK
dash   0.5.12-5   OK
libunistring-debuginfo 1.2-1  OK
libunistring-devel 1.2-1  OK
libunistring5  1.2-1  OK
tar1.35-2 OK

CYGWIN_NT-10.0-22631 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin

Then, `HOME=/tmp asy -vv -f pdf test` hanged.
And, asy invoked by gdb got a siganl SIGTRAP and stopped.




Rolling back cygwin packages has almost no effect.
Very weird... 

Now, I suspect any recent Windows Update might have to do with the issue...
(just because no other idea comes to me).
Not confirmed 


Lem


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

[PATCH] Cygwin: disable high-entropy VA for ldh

2024-05-27 Thread Jeremy Drake via Cygwin-patches

If ldd is run against a DLL or EXE which links to the Cygwin DLL, ldh
will end up loading the Cygwin DLL dynamically, much like cygcheck or
strace.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
Signed-off-by: Jeremy Drake 
---
 winsup/utils/mingw/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/winsup/utils/mingw/Makefile.am b/winsup/utils/mingw/Makefile.am
index d9557d8b50..7f7317ae15 100644
--- a/winsup/utils/mingw/Makefile.am
+++ b/winsup/utils/mingw/Makefile.am
@@ -38,6 +38,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
 cygwin_console_helper_SOURCES = cygwin-console-helper.cc

 ldh_SOURCES = ldh.cc
+ldh_LDFLAGS = ${AM_LDFLAGS} -Wl,--disable-high-entropy-va

 strace_SOURCES = \
path.cc \
-- 
2.45.1.windows.1

Re: frequent hangs running ldd

2024-05-27 Thread 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

Re: frequent hangs running ldd

2024-05-27 Thread 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: new git update fails with fatal: fetch-pack: invalid index-pack output

2024-05-27 Thread 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: Please update nasm package

2024-05-27 Thread Takashi Yano via Cygwin-apps

On Tue, 28 May 2024 07:50:08 +0900
Takashi Yano via Cygwin-apps  wrote:
> On Mon, 27 May 2024 21:18:08 +0200
> Michal Feix  wrote:
> > > I'm planning to submit ITP for dav1d
> > > https://code.videolan.org/videolan/dav1d
> > > and tried to build it on cygwin, however, it failed because
> > > nasm is too old. The current stable version is 2.16.03 while
> > > cygwin package version is 2.13.01.
> > > 
> > > Could the maintainer please update the nasm package?
> > 
> > Hi Takashi, I will have a look into this troghout the rest of this week.
> 
> Thanks for quick response!


I think it's unnecessary meddling,
v2.16.03 can be successfully built by the cygport file:

NAME="nasm"
VERSION=2.16.03
RELEASE=1
LICENSE="BSD 2-Clause"
CATEGORY="Devel"
SUMMARY="The Netwide Assembler"
DESCRIPTION="NASM is a widespread, portable, very flexible and mature
assembler tool with support for many output formats licensed under the
2-clause BSD licence."
HOMEPAGE="http://www.nasm.us/;
SRC_URI="http://www.nasm.us/pub/nasm/releasebuilds/${PV}/${P}.tar.xz;

src_compile() {
cd ${B}
cygconf
cygmake
}

-- 
Takashi Yano

Re: Please update nasm package

2024-05-27 Thread Takashi Yano via Cygwin-apps

On Mon, 27 May 2024 21:18:08 +0200
Michal Feix  wrote:
> > I'm planning to submit ITP for dav1d
> > https://code.videolan.org/videolan/dav1d
> > and tried to build it on cygwin, however, it failed because
> > nasm is too old. The current stable version is 2.16.03 while
> > cygwin package version is 2.13.01.
> > 
> > Could the maintainer please update the nasm package?
> 
> Hi Takashi, I will have a look into this troghout the rest of this week.

Thanks for quick response!


-- 
Takashi Yano

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

2024-05-27 Thread 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: [PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`

On 25/05/2024 08:25, Daisuke Fujimura via Cygwin-apps wrote:

Having seen this commit (
https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831
),
I understand that this is problematic from a reproducibility point of
view, but I would like to be able to specify a `-fdebug-prefix-map`
because C sources with code like `#include __FILE__` cannot be
compiled.

https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302

```
/cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10:
fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file
or directory
359 | #include __FILE__
| ^~~~
compilation terminated.
```

The patch is as follows.

Thanks very much for the patch.

Yeah, I tripped over this when I was testing your previous patch.

This seems like a generic problem which everyone is going to have with
ruby, though. And from a brief look at the debug_counter.h header, it
does seem like a case of excessive cleverness - on first glance, it
looks like this could just be written using a separate header, rather
than recursively including itself with some define set...

(and I guess it's actually a gcc bug, or at least misfeature, that you
can make '#include __FILE__' do something other than it's plain meaning)

Nevertheless, I guess this is needed.

Shell variable names in the patch should be changed to appropriate ones.

Yeah, not sure what a good name for this is. Something like
'DEBUGINFO_ONLY_DEBUG_PREFIX_MAP', maybe?

It needs to be mentioned in the documentation somewhere, as well.

Re: calm: SPDX licence list data update please


On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Can we please get the SPDX licence list data updated in calm to 3.24 
sometime if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on 
that is 30.0.0, and moving to a later one has some wrinkles, since 
various pieces of interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:


[...]


If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license 
data, ideally we'd have something that read the official SPDX data 
(ratelimited to once per day or something. It looks like maybe this 
would possible to do by feeding our own license list into the module 
rather than using it's built in one, but one could hope for this to be 
built in already...)


It would also be useful if it could also be taught to accept 
'LicenseRef-.*' identifiers.


So, suggestions on a different module to use, or patches to make this 
work better, or cogent arguments why we should just remove this 
validation are all welcome.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.

Re: Package import request from CTM


On 27/05/2024 20:39, Michal Feix via Cygwin-apps wrote:
Dear all, as suggested on https://cygwin.com/packaging/repos.html let me 
kindly ask for an import of a 'nasm' package history from CTM into GIT 
repository.


Sure, no problem.

History is now imported at: https://cygwin.com/cgit/cygwin-packages/nasm/

I've given it a brief look over and it seems reasonable, but please 
check that it's OK before you start using it.

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

2024-05-27 Thread 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

2024-05-27 Thread 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: SSH key update


On 27/05/2024 20:20, Michal Feix via Cygwin-apps wrote:

 BEGIN SSH2 PUBLIC KEY 
Comment: "3072-bit RSA, converted by feixm@michal-pc from OpenSSH"
B3NzaC1yc2EDAQABAAABgQDjQ9jbOytPr/sPDwIbjtFeJqBuDymxzuicJ8NpIN
Osoxkagb0WOLPsSjTgDbftDTCw1QOvCrVP09KvLY76MK8zNIt/97N7w/OmB0iWv9v1LEuT
sFAqDlC4jRVMC4pabidTqDZy0nVC54POIwYd4N65k7fxwGGU77OaZeKpKRRYeTekVSSOoc
jmesIhl+StI8kkPPIZMNpNfsm7DisPoqwZdxxrpCir8xmOMOwU9Wt7CYS+hDqDXSky067O
jn0JVty4utXNv/JzVABmiiEpjnFQSwja0vgrbigOrrycJJuGwv4RiYTK63BHfoKgeX1Wqc
pxNsvCw7RYumGGXjhSGBicDTM9X81hxEJpzzKNkWsAbjed1HRZ8DgQmTzQPT/mUUB+hD/r
7NYoxzEDvDV0hYpuk89j+7XnqaAltEIkXy0sYGsWpp8AJGDkSlHJDGxzlQAqmgDXyijJpS
xgEUxl4nkj8ArBJaFW2mGZxdCDUqMJbYRh1mAfExc+EK2CrkgmlFk=
 END SSH2 PUBLIC KEY 



Name: Michal Feix
Updating ssh key for Michal Feix
Fingerprint: 3072 SHA256:Ie/gfi0gbgbawKADzR/9W2sroK40405A5UGhogoLB5o no comment 
(RSA)

Done. Thanks.

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

2024-05-27 Thread 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

Package import request from CTM

2024-05-27 Thread Michal Feix via Cygwin-apps


Dear all, as suggested on https://cygwin.com/packaging/repos.html let me kindly 
ask for an import of a 'nasm' package history from CTM into GIT repository.

Best,

--
Michal Feix

SSH key update

2024-05-27 Thread Michal Feix via Cygwin-apps


Name: Michal Feix
 BEGIN SSH2 PUBLIC KEY 
Comment: "3072-bit RSA, converted by feixm@michal-pc from OpenSSH"
B3NzaC1yc2EDAQABAAABgQDjQ9jbOytPr/sPDwIbjtFeJqBuDymxzuicJ8NpIN
Osoxkagb0WOLPsSjTgDbftDTCw1QOvCrVP09KvLY76MK8zNIt/97N7w/OmB0iWv9v1LEuT
sFAqDlC4jRVMC4pabidTqDZy0nVC54POIwYd4N65k7fxwGGU77OaZeKpKRRYeTekVSSOoc
jmesIhl+StI8kkPPIZMNpNfsm7DisPoqwZdxxrpCir8xmOMOwU9Wt7CYS+hDqDXSky067O
jn0JVty4utXNv/JzVABmiiEpjnFQSwja0vgrbigOrrycJJuGwv4RiYTK63BHfoKgeX1Wqc
pxNsvCw7RYumGGXjhSGBicDTM9X81hxEJpzzKNkWsAbjed1HRZ8DgQmTzQPT/mUUB+hD/r
7NYoxzEDvDV0hYpuk89j+7XnqaAltEIkXy0sYGsWpp8AJGDkSlHJDGxzlQAqmgDXyijJpS
xgEUxl4nkj8ArBJaFW2mGZxdCDUqMJbYRh1mAfExc+EK2CrkgmlFk=
 END SSH2 PUBLIC KEY

Re: Please update nasm package

2024-05-27 Thread Michal Feix via Cygwin-apps


Hi,

I'm planning to submit ITP for dav1d
https://code.videolan.org/videolan/dav1d
and tried to build it on cygwin, however, it failed because
nasm is too old. The current stable version is 2.16.03 while
cygwin package version is 2.13.01.

Could the maintainer please update the nasm package?

Hi Takashi, I will have a look into this troghout the rest of this week.

Best,

--
Michal Feix

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

2024-05-27 Thread 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: Cygwin setup-x86_64.exe cannot install into UNC paths...

2024-05-27 Thread 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: Installing Cygwin as normal user in nonstandard location?

2024-05-27 Thread 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 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: Installing Cygwin as normal user in nonstandard location?

2024-05-27 Thread 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&&& 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...

2024-05-27 Thread 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 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&&& 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

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

2024-05-27 Thread 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&&& 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: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

2024-05-27 Thread 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 <http://gnu.org/licenses/gpl.html>
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:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

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

Please update nasm package

2024-05-27 Thread Takashi Yano via Cygwin-apps

Hi,

I'm planning to submit ITP for dav1d
https://code.videolan.org/videolan/dav1d
and tried to build it on cygwin, however, it failed because
nasm is too old. The current stable version is 2.16.03 while
cygwin package version is 2.13.01.

Could the maintainer please update the nasm package?

-- 
Takashi Yano

Re: Installing Cygwin as normal user in nonstandard location?

2024-05-27 Thread 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 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

2024-05-26 Thread 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?


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

2024-05-26 Thread Brian Inglis via Cygwin


On 2024-05-26 06: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. Can you
please upgrade, check the problem is still recurring, and provide the
output from `cygcheck -srv >cygcheck.out`?


I got the same symptom yesterday from the previous git version on the recently 
updated curl repo, and just put it down to traffic, as `git pull --ff` worked 
immediately after, as did a later `git remote update`:


$ git remote update
remote: Enumerating objects: 6617, done.
remote: Counting objects: 100% (4385/4385), done.
remote: Compressing objects: 100% (280/280), done.
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 
8)
error: 4751 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
$ git --version
git version 2.43.0

Of course, it could also be some issue with my latest curl build! ;^>

--
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: Installing Cygwin as normal user in nonstandard location?

2024-05-26 Thread Andrey Repin via Cygwin

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.

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


-- 
With best regards,
Andrey Repin
Sunday, May 26, 2024 20:25:48

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: new git update fails with fatal: fetch-pack: invalid index-pack output

2024-05-26 Thread Adam Dinwoodie via Cygwin

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. Can you
please upgrade, check the problem is still recurring, and provide the
output from `cygcheck -srv >cygcheck.out`?

Sun 26 May 12:57 $ 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 | 3.60 MiB/s, done.
Resolving deltas: 100% (16522/16522), done.

Sun 26 May 12:58 $ git --version
git version 2.45.1

Sun 26 May 12:58 $ cygcheck -c git
Cygwin Package Information
Package  VersionStatus
git  2.45.1-1   OK

Sun 26 May 12:59 $ type git
git is hashed (/usr/bin/git)

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

Add support for epoll.h to Cygwin

2024-05-26 Thread Đoàn Bảo Trung via Cygwin-apps

Dear Cygwin team,

In order to extend Cygwin support for Linux applications. Please consider
adding support for epoll.h into your system.

I found some sources that may work. Please check.

Upoll:
https://drive.google.com/file/d/1shiAHs_igbJt8MDyjShVnSM8uPOaAmZY/view?usp=sharing
Cygepoll:
https://drive.google.com/file/d/1Uxg6JsGnMbSXBNmp-yB4ttzgG9spsPo8/view?usp=sharing

With these 2 we can add support for sys/epoll.h which can help to increase
our community users.

-- 
Thanks and best regard,
Đoàn Bảo Trung
Phone: 0909 189 103

Re: Installing Cygwin as normal user in nonstandard location?

2024-05-26 Thread Martin Wege via Cygwin

On Sun, May 26, 2024 at 2:14 AM Bill Stewart via Cygwin
 wrote:
>
> On Sat, May 25, 2024 at 3:54 PM Martin Wege 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.
> >
>
> (?) 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? Can Cygwin installations
installed as non-admin interact via Windows REGISTRY, or other
unexpected ways? So testing by a non-expert like me might not uncover
such things immediately, so I better ask the experts here

@Corinna Vinschen ?

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: Installing Cygwin as normal user in nonstandard location?

2024-05-26 Thread Andrey Repin via Cygwin

Greetings, Martin Wege!

> Can Cygwin be installed as a normal user (without Admin rights) in a
> nonstandard location, like C.\Users\martinwege\cygwinroot36\...)?

Yes, and there's no such thing as "standard location".

> Also, can this be done for more than one Cygwin version, e.g. I'd like
> to test multiple Cygwin versions in parallel.

Yes, Cygwin by default does not integrate into %PATH% and multiple different
versions can be run even at the same time.


-- 
With best regards,
Andrey Repin
Sunday, May 26, 2024 08:55: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: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

2024-05-25 Thread Lemures Lemniscati via Cygwin

On Wed, 27 Mar 2024 16:51:48 -0400, Ken Brown via Cygwin-announce
> * asymptote-2.88-1
> 
> Asymptote is a powerful descriptive vector graphics language for technical 
> drawing, inspired by MetaPost but with an improved C++-like syntax.  
> Asymptote provides for figures the same high-quality typesetting that LaTeX 
> does for scientific text.

Hi!

Thank you for maintaining cygwin texlive.


I've updated texlive 20240312-1 and asymptote-2.88-1.

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


Using configuration directory /home/XXX/.asy
Using history /home/XXX/.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


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

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

2024-05-25 Thread David Dyck via Cygwin

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.

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

2024-05-25 Thread Bill Stewart via Cygwin

On Sat, May 25, 2024 at 3:54 PM Martin Wege 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.
>

(?) Why ask when you can just try both scenarios pretty easily?

Bill

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

Updated: curl/libcurl-doc/-devel/4, mingw64-x86_64-curl 8.8

2024-05-25 Thread Cygwin curl Maintainer

Multi-protocol file transfer tool

Command line tool and Library supporting transferring files with
URL syntax, using FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, and
FILE, SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form
based upload, proxies, cookies, user+password authentication (Basic,
Digest, NTLM, Negotiate...), file transfer resume, proxy tunneling and a
busload of other useful tricks.

For more information see the project home page:

https://curl.se/

The following packages have been upgraded in the Cygwin distribution:

* curl  8.8
* libcurl-doc   8.8
* libcurl-devel 8.8
* libcurl4  8.8
* mingw64-x86_64-curl   8.8

This Cygwin release includes additional documentation including the
ebook Everything Curl in ePub and PDF formats, curl.txt, and MarkDown
documents.

For information on security vulnerabilities and fixes see:

https://curl.se/docs/security.html

As there are many functions and changes each release see below
or read /usr/share/doc/curl/RELEASE-NOTES after installation;
for complete details of changes see:

/usr/share/doc/curl/CHANGES
or
https://curl.se/changes.html


curl and libcurl 8.8.0  2024-05-22

Public curl releases:257
Command line options:259
curl_easy_setopt() options:  305
Public functions in libcurl:  94
Contributors:   3173

This release includes the following changes:

- curl_version_info: provide librtmp version
- file: add support for directory listings
- idn: add native AppleIDN (icucore) support for macOS/iOS
- lib: add curl_multi_waitfds
- mbedTLS: implement CURLOPT_SSL_CIPHER_LIST option
- NTLM_WB: drop support
- TLS: add support for ECH (Encrypted Client Hello)
- urlapi: add CURLU_GET_EMPTY for empty queries and fragments

Planned upcoming removals include:

- support for space-separated NOPROXY patterns

  See https://curl.se/dev/deprecate.html for details

This release includes the following known bugs:

- see docs/KNOWN_BUGS (https://curl.se/docs/knownbugs.html)

This release includes the following bugfixes:

- appveyor: drop unnecessary `--clean-first` cmake option
- appveyor: guard against crash-build with VS2008
- appveyor: make gcc 6 mingw64 job build-only
- asyn-thread: fix curl_global_cleanup crash in Windows
- asyn-thread: fix Curl_thread_create result check
- autotools: delete unused functions
- autotools: fix `HAVE_IOCTLSOCKET_FIONBIO` test for gcc 14
- autotools: only probe for SGI MIPS compilers on IRIX
- bearssl: fix compiler warnings
- bearssl: use common code for cipher suite lookup
- bufq: remove duplicate word in comment
- BUG-BOUNTY.md: clarify the third party situation
- build: prefer `USE_IPV6` macro internally (was: `ENABLE_IPV6`)
- build: remove MacOSX-Framework script
- cd2nroff/manage: use UTC when SOURCE_DATE_EPOCH is set
- cf-https-connect: use timeouts as unsigned ints
- cf-socket: don't try getting local IP without socket
- cf-socket: remove references to l_ip, l_port
- ci: add curl-for-win builds: Linux MUSL, macOS, Windows
- cmake: add `BUILD_EXAMPLES` option to build examples
- cmake: add librtmp/rtmpdump option and detection
- cmake: check fseeko after detecting HAVE_FILE_OFFSET_BITS
- cmake: do not pass linker flags to the static library tool
- cmake: enable `-pedantic-errors` for clang when `CURL_WERROR=ON`
- cmake: FindNGHTTP2 add static lib name to find_library call
- cmake: fix `CURL_WERROR=ON` for old CMake and use it in GHA/linux-old
- cmake: fix `HAVE_IOCTLSOCKET_FIONBIO` test with gcc 14
- cmake: fixup `DEPENDS` filename
- cmake: forward `USE_LIBRTMP` option to C
- cmake: generate misc manpages and install `mk-ca-bundle.pl`
- cmake: initialize `BUILD_TESTING` before first use
- cmake: speed up libcurl doc building again
- cmake: tidy-up to use `WORKING_DIRECTORY`
- cmake: use namespaced custom target names
- cmdline-docs: fix make install with configure --disable-docs
- configure: error on missing perl if docs or manual is enabled
- configure: make --disable-docs imply --disable-manual
- content_encoding: brotli and others, pass through 0-length writes
- content_encoding: ignore duplicate chunked encoding
- content_encoding: reject transfer-encoding after chunked
- contrithanks: honor `CURLWWW` variable
- curl-confopts.m4: define CARES_NO_DEPRECATED when c-ares is used
- curl.h: change CURL_SSLVERSION_* from enum to defines
- curl: make --help adapt to the terminal width
- curl: use curl_getenv instead of the curlx_ version
- Curl_creader_read: init two variables to avoid using them uninited
- curl_easy_pause.md: use correct defines in example
- curl_getdate.md: document two-digit year handling
- curl_global_trace.md: shorten the description
- curl_multibyte: remove access() function wrapper for Windows
- curl_path: make Curl_get_pathname use dynbuf
- curl_setup.h: add support for IAR compiler
- curl_setup.h: detect 'inline' support
- curl_sha512_256: do not use

LD_PRELOAD for Win32?

2024-05-25 Thread Martin Wege via Cygwin

Hello,

Does Cygwin or Win32 have something like LD_PRELOAD, so I can
override/substitute functions in a DLL or EXE, like it is common for
UNIX/Linux ELF shared libraries?

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

Installing Cygwin as normal user in nonstandard location?

2024-05-25 Thread Martin Wege via Cygwin

Hello,

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.

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

git 2.45.1-1

2024-05-25 Thread Adam Dinwoodie via Cygwin-announce



The following packages have been uploaded to the Cygwin distribution:

* git-2.45.1-1
* git-cvs-2.45.1-1
* git-debuginfo-2.45.1-1
* git-email-2.45.1-1
* git-gui-2.45.1-1
* git-p4-2.45.1-1
* git-svn-2.45.1-1
* gitk-2.45.1-1
* gitweb-2.45.1-1

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows.



-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
<https://cygwin.com/mailman/options/cygwin-announce>, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
<https://sourceware.org/lists.html#unsubscribe>.

[PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`

2024-05-25 Thread Daisuke Fujimura via Cygwin-apps

Having seen this commit (
https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831
),
I understand that this is problematic from a reproducibility point of
view, but I would like to be able to specify a `-fdebug-prefix-map`
because C sources with code like `#include __FILE__` cannot be
compiled.

https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302

```
/cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10:
fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file
or directory
359 | #include __FILE__
| ^~~~
compilation terminated.
```

The patch is as follows.

Shell variable names in the patch should be changed to appropriate ones.


force-debug-prefix-map.diff
Description: Binary data

Re: frequent hangs running ldd

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

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

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.

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

On Fri, 24 May 2024, Jeremy Drake wrote:

> On Fri, 24 May 2024, Jeremy Drake wrote:
>
> > Windbg reports that ldh.exe is already being debugged.  I was able to do a
> > "non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
> > to deal with the split debug symbols (gnulink?).  I don't know if gdb can
> > do a non-invasive attach like that (or open a minidump assuming one could
> > be made from a non-invasize attach in windbg).
>
> Seems it can, and at least lldb can load a minidump (unfortunately it's
> not showing source file/line info like gdb does):
> (lldb) bt
> * thread #1, stop reason = Exception 0x8007 encountered at address
> 0x00
>   * frame #0: 0x000180178837 msys-2.0.dll`cygheap_init()

It appears that cygheap is NULL, so I'm guessing that VirtualAlloc failed.
!gle in windbg shows
0:000> !gle
LastErrorValue: (Win32) 0x1e7 (487) - Attempt to access invalid address.
LastStatusValue: (NTSTATUS) 0xc018 - {Conflicting Address Range}  The
specified address range conflicts with the address space.

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
BaseAddress  EndAddress+1RegionSize Type   State
 Protect Usage
--
+5`e81810008`05a02`1d87f000 MEM_FREE
PAGE_NOACCESS  Free
+8`05a08`05b570000`00157000 MEM_PRIVATE MEM_RESERVE 
   
 8`05b570008`05b580000`1000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE PEB[4628]
 8`05b580008`05b5a0000`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE TEB[~0; 4628.31ac]
 8`05b5a0008`05b5c0000`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE TEB[~1; 4628.4aac]
 8`05b5c0008`05b5e0000`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE TEB[~2; 4628.5840]
 8`05b5e0008`05b60`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE TEB[~3; 4628.6b9c]
 8`05b68`05c00`000a MEM_PRIVATE MEM_RESERVE 
   
+8`05c08`05df60000`001f6000 MEM_PRIVATE MEM_RESERVE 
   Stack  [~0; 4628.31ac]
 8`05df60008`05df90000`3000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE | PAGE_GUARDStack  [~0; 4628.31ac]
 8`05df90008`05e00`7000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE Stack  [~0; 4628.31ac]
+8`05e08`05ffb0000`001fb000 MEM_PRIVATE MEM_RESERVE 
   Stack  [~1; 4628.4aac]
 8`05ffb0008`05ffe0000`3000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE | PAGE_GUARDStack  [~1; 4628.4aac]
 8`05ffe0008`06000`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE Stack  [~1; 4628.4aac]
+8`06008`061fb0000`001fb000 MEM_PRIVATE MEM_RESERVE 
   Stack  [~2; 4628.5840]
 8`061fb0008`061fe0000`3000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE | PAGE_GUARDStack  [~2; 4628.5840]
 8`061fe0008`06200`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE Stack  [~2; 4628.5840]
+8`06208`063fb0000`001fb000 MEM_PRIVATE MEM_RESERVE 
   Stack  [~3; 4628.6b9c]
 8`063fb0008`063fe0000`3000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE | PAGE_GUARDStack  [~3; 4628.6b9c]
 8`063fe0008`06400`2000 MEM_PRIVATE MEM_COMMIT  
PAGE_READWRITE Stack  [~3; 4628.6b9c]
+8`0640  19e`6440  196`5e00 MEM_FREE
PAGE_NOACCESS  Free

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

2024-05-24 Thread Mark Geisert via Cygwin


On 5/24/2024 3:26 PM, Jeremy Drake via Cygwin wrote:

On Sat, 25 May 2024, Takashi Yano wrote:


On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:

Thanks for the report. However, I cannot reproduce the issue.
If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
bug but a windows bug.

By any chance, is the number of processes that attach to the same pty more
than 32768 in your environment?



I doubt it, I was running a shell with this command:
find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;


Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...



Windbg reports that ldh.exe is already being debugged.  I was able to do a
"non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
to deal with the split debug symbols (gnulink?).  I don't know if gdb can
do a non-invasive attach like that (or open a minidump assuming one could
be made from a non-invasize attach in windbg).


ldd is the debugger of ldh. I found that Sysinternals Process Explorer 
can attach to ldh, show the threads, and can get stack backtraces which 
are refreshable. You have to convert addresses shown there into 
source-relevant addresses manually.


I'm bowing out for now as I think Takashi has a handle on this.
Cheers,

..mark


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

On Fri, 24 May 2024, Jeremy Drake wrote:

> Windbg reports that ldh.exe is already being debugged.  I was able to do a
> "non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
> to deal with the split debug symbols (gnulink?).  I don't know if gdb can
> do a non-invasive attach like that (or open a minidump assuming one could
> be made from a non-invasize attach in windbg).

Seems it can, and at least lldb can load a minidump (unfortunately it's
not showing source file/line info like gdb does):
(lldb) bt
* thread #1, stop reason = Exception 0x8007 encountered at address
0x00
  * frame #0: 0x000180178837 msys-2.0.dll`cygheap_init()
frame #1: 0x000180178b89 msys-2.0.dll`setup_cygheap()
frame #2: 0x0001800488bd msys-2.0.dll`dll_crt0_0()
frame #3: 0x00018007197c msys-2.0.dll`dll_entry(h=0x00018004, 
reason=, static_load=)
frame #4: 0x7ffece99869f 
ntdll.dll`RtlActivateActivationContextUnsafeFast + 303
frame #5: 0x7ffece9dd03d ntdll.dll`RtlEnumerateEntryHashTable + 957
frame #6: 0x7ffece9dcdee ntdll.dll`RtlEnumerateEntryHashTable + 366
frame #7: 0x7ffece9dce60 ntdll.dll`RtlEnumerateEntryHashTable + 480
frame #8: 0x7ffece9dce60 ntdll.dll`RtlEnumerateEntryHashTable + 480
frame #9: 0x7ffece9dce60 ntdll.dll`RtlEnumerateEntryHashTable + 480
frame #10: 0x7ffece9dce60 ntdll.dll`RtlEnumerateEntryHashTable + 480
frame #11: 0x7ffece99d62d ntdll.dll`RtlCopyUnicodeString + 1293
frame #12: 0x7ffece998940 ntdll.dll`RtlImageRvaToSection + 592
frame #13: 0x7ffece988cac ntdll.dll`RtlUnicodeToCustomCPN + 1020
frame #14: 0x7ffece99a25a ntdll.dll`LdrLoadDll + 250
frame #15: 0x7ffecbe961e2 KERNELBASE.dll`LoadLibraryExW + 370
frame #16: 0x7ff6df3414ba ldh.exe
frame #17: 0x7ff6df3412ee ldh.exe
frame #18: 0x7ff6df341406 ldh.exe
frame #19: 0x7ffecdc6257d kernel32.dll`BaseThreadInitThunk + 29
frame #20: 0x7ffece9caa48 ntdll.dll`RtlUserThreadStart + 40
msys-2.0.dll`cygheap_init:
0x180178750 <+0>:   pushq  %rbx
0x180178751 <+1>:   subq   $0x20, %rsp
0x180178755 <+5>:   leaq   0x102de4(%rip), %rcx ; _sys_nerr + 148864
0x18017875c <+12>:  leaq   0x153b2f(%rip), %rdx ; __infinity + 5074
0x180178763 <+19>:  callq  0x1800cce50; muto::init at 32:1
0x180178768 <+24>:  movq   0x102e01(%rip), %rcx ; _sys_nerr + 148912
0x18017876f <+31>:  leaq   0x102e02(%rip), %rax ; _sys_nerr + 148920
0x180178776 <+38>:  cmpq   %rax, %rcx
0x180178779 <+41>:  je 0x1801787d0; <+128> at 294:47
0x18017877b <+43>:  cmpq   $0x0, 0x4870(%rcx)
0x180178783 <+51>:  je 0x1801787a0; <+80> at 311:3
0x180178785 <+53>:  cmpq   $0x0, 0x48a0(%rcx)
0x18017878d <+61>:  je 0x1801787b5; <+101> at 312:14
0x18017878f <+63>:  addq   $0x20, %rsp
0x180178793 <+67>:  popq   %rbx
0x180178794 <+68>:  jmp0x180178680; init_cygheap::init_tls_list at 
638:1
0x180178799 <+73>:  nopl   (%rax)
0x1801787a0 <+80>:  cmpq   $0x0, 0x48a0(%rcx)
0x1801787a8 <+88>:  movq   $0x3, 0x4888(%rcx)
0x1801787b3 <+99>:  jne0x18017878f; <+63> at 314:1
0x1801787b5 <+101>: callq  0x1800c0c10; sigalloc at 125:1
0x1801787ba <+106>: movq   0x102daf(%rip), %rcx ; _sys_nerr + 148912
0x1801787c1 <+113>: addq   $0x20, %rsp
0x1801787c5 <+117>: popq   %rbx
0x1801787c6 <+118>: jmp0x180178680; init_cygheap::init_tls_list at 
638:1
0x1801787cb <+123>: nopl   (%rax,%rax)
0x1801787d0 <+128>: movabsq $0x8, %rbx ; imm = 0x8
0x1801787da <+138>: movl   $0x1, %r9d
0x1801787e0 <+144>: movl   $0x2000, %r8d ; imm = 0x2000
0x1801787e6 <+150>: movabsq $0x2, %rdx ; imm = 0x2
0x1801787f0 <+160>: movq   %rbx, %rcx
0x1801787f3 <+163>: callq  0x180217090; _alloca + 4336
0x1801787f8 <+168>: movq   %rbx, %rcx
0x1801787fb <+171>: movl   $0x4, %r9d
0x180178801 <+177>: movl   $0x1000, %r8d ; imm = 0x1000
0x180178807 <+183>: movl   $0x30, %edx ; imm = 0x30
0x18017880c <+188>: movq   %rax, 0x102d5d(%rip) ; _sys_nerr + 148912
0x180178813 <+195>: callq  0x180217090; _alloca + 4336
0x180178818 <+200>: movq   %rax, %rcx
0x18017881b <+203>: movq   %rax, 0x102d4e(%rip) ; _sys_nerr + 148912
0x180178822 <+210>: leaq   0x48e0(%rax), %rax
0x180178829 <+217>: movq   %rax, 0x102d38(%rip) ; _sys_nerr + 148904
0x180178830 <+224>: leaq   0x3d319(%rip), %rax ; __utf8_mbtowc at 534:1
->  0x180178837 <+231>: movq   %rax, (%rcx)
0x18017883a <+234>: movl   $0x12, 0x4828(%rcx)
0x180178844 <+244>: movq   $0x0, 0x4830(%rcx)
0x18017884f <+255>: jmp0x18017877b; <+43> at 309:3

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

Re: frequent hangs running ldd

On Sat, 25 May 2024, Takashi Yano wrote:

> On Fri, 24 May 2024 14:46:40 -0700 (PDT)
> Jeremy Drake wrote:
> > > Thanks for the report. However, I cannot reproduce the issue.
> > > If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> > > bug but a windows bug.
> > >
> > > By any chance, is the number of processes that attach to the same pty more
> > > than 32768 in your environment?
> > >
> >
> > I doubt it, I was running a shell with this command:
> > find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;
>
> Thanks for the details. I could reproduce the issue.
> It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
> However, gdb cannot attach to ldh.exe...
>

Windbg reports that ldh.exe is already being debugged.  I was able to do a
"non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
to deal with the split debug symbols (gnulink?).  I don't know if gdb can
do a non-invasive attach like that (or open a minidump assuming one could
be made from a non-invasize attach in windbg).

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

2024-05-24 Thread Mark Geisert via Cygwin


On 5/24/2024 3:17 PM, Takashi Yano via Cygwin wrote:

On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:

Thanks for the report. However, I cannot reproduce the issue.
If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
bug but a windows bug.

By any chance, is the number of processes that attach to the same pty more
than 32768 in your environment?



I doubt it, I was running a shell with this command:
find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;


Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...


I could reproduce this too, even to not being able to attach gdb. If you 
exit that gdb session, I think you'll find the target process still 
stuck. You might be able to attach gdb again and it'll work. Here's what 
I found:


~ gdb -q /usr/bin/ldd
Reading symbols from /usr/bin/ldd...
Reading symbols from /usr/lib/debug//usr/bin/ldd.exe.dbg...
(gdb) att 6807
Attaching to program: /usr/bin/ldd, process 9732
[New Thread 9732.0x36a4]
[New Thread 9732.0x2bac]
(gdb) i thr
  Id   Target IdFrame
  1Thread 9732.0x31a8 "ldd" 0x7ff8524f0b04 in 
ntdll!ZwWaitForDebugEvent

() from /c/Windows/SYSTEM32/ntdll.dll
  2Thread 9732.0x36a4 "sig" 0x7ff8524ed174 in ntdll!ZwReadFile ()
   from /c/Windows/SYSTEM32/ntdll.dll
* 3Thread 9732.0x2bac   0x7ff8524f0be1 in ntdll!DbgBreakPoint ()
   from /c/Windows/SYSTEM32/ntdll.dll
(gdb) thr 1
[Switching to thread 1 (Thread 9732.0x31a8)]
#0  0x7ff8524f0b04 in ntdll!ZwWaitForDebugEvent ()
   from /c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x7ff8524f0b04 in ntdll!ZwWaitForDebugEvent ()
   from /c/Windows/SYSTEM32/ntdll.dll
#1  0x7ff850165796 in WaitForDebugEventEx ()
   from /c/Windows/System32/KERNELBASE.dll
#2  0x000100401ba1 in report (
in_fn=0x89200 "/usr/bin/cygdialog-14.dll",
multiple=multiple@entry=false)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:325
#3  0x0001004026de in main (argc=, argv=0xa000004d0)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:439
(gdb) f 2
#2  0x000100401ba1 in report (
in_fn=0x89200 "/usr/bin/cygdialog-14.dll",
multiple=multiple@entry=false)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:325
325   if (!WaitForDebugEvent (, INFINITE))
(gdb) list
320
321   while (1)
322 {
323   bool exitnow = false;
324   DWORD cont = DBG_CONTINUE;
325   if (!WaitForDebugEvent (, INFINITE))
326 break;
327   switch (ev.dwDebugEventCode)
328 {
329 case CREATE_PROCESS_DEBUG_EVENT:
(gdb)

..mark

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

2024-05-24 Thread Takashi Yano via Cygwin

On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:
> > Thanks for the report. However, I cannot reproduce the issue.
> > If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> > bug but a windows bug.
> >
> > By any chance, is the number of processes that attach to the same pty more
> > than 32768 in your environment?
> >
> 
> I doubt it, I was running a shell with this command:
> find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;

Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...

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

On Sat, 25 May 2024, Takashi Yano wrote:

> Thanks for the report. However, I cannot reproduce the issue.
> If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> bug but a windows bug.
>
> By any chance, is the number of processes that attach to the same pty more
> than 32768 in your environment?
>

I doubt it, I was running a shell with this command:
find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;

This was in Windows Terminal, msys2-runtime 3.5.3, on Windows 11
10.0.22631.3593.  (I realized I forgot to include these details).

I will attempt to reproduce this in Windows Sandbox with Cygwin next.

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

2024-05-24 Thread Takashi Yano via Cygwin

On Sat, 25 May 2024 04:54:24 +0900
Takashi Yano wrote:
> By any chance, is the number of processes that attach to the same pty more
> than 32768 in your environment?

s/32768/8192/

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

2024-05-24 Thread Takashi Yano via Cygwin

On Fri, 24 May 2024 11:50:35 -0700 (PDT)
Jeremy Drake wrote:
> Seen on msys2, but doesn't seem specific to it.
> 
> Frequently, when running ldd in a loop, it will hang.  I managed to get a
> backtrace from gdb with symbols:
> 
> (gdb) bt
> #0  0x7ffecea0fa34 in ntdll!ZwDeviceIoControlFile ()
>from /c/Windows/SYSTEM32/ntdll.dll
> #1  0x7ffecbead7a9 in KERNELBASE!GetConsoleScreenBufferInfoEx ()
>from /c/Windows/System32/KERNELBASE.dll
> #2  0x7ffecbef58dc in KERNELBASE!GetConsoleTitleW ()
>from /c/Windows/System32/KERNELBASE.dll
> #3  0x7ffecbfb8195 in KERNELBASE!GetConsoleProcessList ()
>from /c/Windows/System32/KERNELBASE.dll
> #4  0x00018015851f in fhandler_pty_common::get_console_process_id (
> pid=19348, match=match@entry=true, cygwin=cygwin@entry=false,
> stub_only=stub_only@entry=false, nat=nat@entry=false)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/pty.cc:95
> #5  0x000180101e3b in fhandler_console::attach_console (
> owner=, err=err@entry=0x0)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:76
> #6  0x000180102d40 in fhandler_console::set_output_mode (m=tty::native,
> t=0x1a0030028, p=0x800021d68)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:853
> #7  0x00018010d6cc in fhandler_console::set_console_mode_to_native ()
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:4189
> #8  0x00018010d71d in ContinueDebugEvent_Hooked (p=26628, t=26656, 
> s=65538)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:4238
> #9  0x000100401bd7 in ?? ()
> #10 0x00010040279f in ?? ()
> #11 0x0001800483a7 in dll_crt0_1 ()
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/dcrt0.cc:1015
> #12 0x000180045f63 in _cygtls::call2 (this=0x7ce00,
> func=0x180047240 , arg=0x0,
> buf=buf@entry=0x7cdf0)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:41
> #13 0x000180046014 in _cygtls::call (func=,
> arg=)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:28
> #14 0x in ?? ()
> 
> Other attempts without symbols showed the same Windows APIs at least.

Thanks for the report. However, I cannot reproduce the issue.
If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
bug but a windows bug.

By any chance, is the number of processes that attach to the same pty more
than 32768 in your environment?

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

frequent hangs running ldd