frequent hangs running ldd
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. -- 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 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
Re: frequent hangs running ldd
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
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
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 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=0xa04d0)
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 (&ev, INFINITE))
(gdb) list
320
321 while (1)
322 {
323 bool exitnow = false;
324 DWORD cont = DBG_CONTINUE;
325 if (!WaitForDebugEvent (&ev, 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
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
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: https://cygwin.com/ml/#unsubscribe-simpl
Re: frequent hangs running ldd
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:
> 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
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: > > > 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
