On 2024-06-24 12:04, Brian Inglis via Cygwin-apps wrote:
> On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote:
>> On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote:
>>> On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote:
>>>> On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote:
>>>>> On 23/06/2024 22:13, Marco Atzeri wrote:
>>>>>> On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote:
>>>>>>> Update to current needed to update libgcrypt if you could please oblige?
>>>>>>>
>>>>>>
>>>>>> unfortunately any recent version up to 1.50 are failing a lot of tests
>>>>>>
>>>>>> PASS: t-version.exe
>>>>>> PASS: t-strerror.exe
>>>>>> fopen failed with bad code: 20
>>>>>> PASS: t-syserror.exe
>>>>>> FAIL: t-lock.exe
>>>>>> FAIL: t-printf.exe
>>>>>> FAIL: t-poll.exe
>>>>>> FAIL: t-b64.exe
>>>>>> FAIL: t-argparse.exe
>>>>>> FAIL: t-logging.exe
>>>>>> PASS: t-stringutils.exe
>>>>>> PASS: t-malloc.exe
>>>>>> =======================================
>>>>>> 6 of 11 tests failed
>>>>>>
>>>>>> I was never able to find a solution, so if any one can look and give any 
>>>>>> suggestion, I will appreciate
>>>>>>
>>>>>> regards
>>>>>> Marco
>>>>>
>>>>>
>>>>> I just rebuilt the old 1.37 and it is reporting the same errors,
>>>>> while in 2020 it was passing all the tests
>>>>>
>>>>> so it seems something else is playing a role here
>>>>>
>>>>> very puzzling
>>>>
>>>> Hi Marco,
>>>>
>>>> I noticed that the build is generating libtool wrapper sources, executables, 
>>>> and shell scripts under .../build/tests/.libs/ for the test programs, so if 
>>>> that also happens with 1.37, that raises my suspicions that what is failing 
>>>> is something to do with those wrappers and Cygwin libtool mods.
>>>
>>> Another possibility is that the failures are caused by a Cygwin bug 
>>> introduced since 2020.  There have been several bugs in Cygwin 3.5.3 that 
>>> have been fixed. Since 3.5.4 hasn't been released yet, you could try the 
>>> latest test release of 3.6, which has all the bug fixes.
>>>
>>> FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: 
>>> SetThreadDescription() failed", followed quickly by a SIGSEGV.  That again 
>>> suggests a possible Cygwin bug.
>>
>> Thanks Ken,
>>
>> Great suggestion - also did strace on t-printf from 1.50 tests/.libs with 
>> src/.libs in the path to pick up test dll and got a loop due to a SEGV on 
>> 0000000500000000 - makes interesting reading, but does not mean much to me - 
>> terminated it eventually.
>> Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized.
>>
>> However, I see no changes since to SetThread related stuff since misc_funcs.cc 
>> in 2022.
>> There may be some issues with Windows error or exception handling, so I will 
>> retry under cygwin... 3.6.0-115...
> 
> No changes after upgrading all cygwin... packages to test 3.6.0-139... including 
> also taking the precaution of running:
> 
> $ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf ...
> $ head /proc/version
> CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64 
> (runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC
> 
> So perhaps the SetThreadDescription stuff needs another look?
> 
> Anyone familiar with that?

I cut down various parts of the program, and finally narrowed it down to gpgrt 
allocation or cygwin allocation corrupting the stack so return fails.
See attached gdb log.

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