Deeper stack trace please

Deeper stack trace please

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Hi,

When Cygwin generates a stacktrace (coredump) is it possible to get more than 16 frames printed out?
Looking at exceptions.cc, seems like not.  Can it please be increased to 32, for example?

Thanks,
Anton


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

Re: Deeper stack trace please

[Mark Geisert]

Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> When Cygwin generates a stacktrace (coredump) is it possible to get more than 16 frames printed out?
> Looking at exceptions.cc, seems like not.  Can it please be increased to 32, for example?

I've submitted a patch for this enhancement.

..mark

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

Re: Configurable stack trace please

[L A Walsh]

On 2019/11/07 13:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> When Cygwin generates a stacktrace (coredump) is it possible to get more than 16 frames printed out?
> Looking at exceptions.cc, seems like not.  Can it please be increased to 32, for example?
>   
---
"For example".  I'm guessing it's a first stab at an amount that might be
right for the program you are debugging?

Would it be possible to put that limit in an ENV var?  Like if "not
set", or
the #frames > (what? 128? 256? 512?) "some limit that is way above what
would be used or wanted", then use 16 frames, else use value in an ENV VAR
like CYGWIN_DBG_UNWIND_STACKFRAMES=32.  Looking through several progs
just now,
the max stack size I saw was about 32 frames, though in a program that was
'hung' (like Firefox et al) I've seen over 100 frames -- but how many are
valid...

But this was a longer trace for syslogd's main thread.

0, ntoskrnl.exe!RtlNumberOfSetBitsUlongPtr+0x1093
1, ntoskrnl.exe!KeReleaseSpinLock+0x81d
2, ntoskrnl.exe!KeWaitForMultipleObjects+0x272
3, ntoskrnl.exe!NtRequestWaitReplyPort+0x434
4, ntoskrnl.exe!FsRtlMdlWriteCompleteDev+0x1ec1
5, ntoskrnl.exe!longjmp+0x5b93
6, ntdll.dll!NtWaitForMultipleObjects+0xa
7, KernelBase.dll!GetCurrentProcess+0x40
8, kernel32.dll!WaitForMultipleObjects+0xb0
9, cygwin1.dll!acl_get_perm+0x4a8c
10, cygwin1.dll!acl_get_perm+0x51b4
11, cygwin1.dll!acl_get_perm+0x5668
12, cygwin1.dll!acl_get_perm+0x5ae7
13, cygwin1.dll!dirname+0x4acc
14, cygwin1.dll!acl_get_perm+0x99da
15, 0x600000750
16, 0x2
17, 0xffffffff
18, 0x100000000
19, 0xffffc330
20, 0xffffc300
21, 0x44
22, 0x600000750
23, 0x2
24, 0xffffc300
25, syslogd.exe+0x156e8
26, 0xffffc2e0
27, 0x4f300000000
28, 0xffffc7c0
29, 0x450230
30, 0x109
31, syslogd.exe+0x107f
-----------------------------------

BTW, for frames 15-31, I'm guessing those are maybe
from inside syslogd(?).

The above is from the tool 'Process Hacker' (it's Hacker in the
exploring/curiosity sense, not in the Cracking sense) with
Win binaries and source downloadable from
https://processhacker.sourceforge.io/.
(V2.39)

It's an enhanced replacement for sysinternals ProcessExplorer, which
is an enhanced replacement for 'Windows Task Manager'.

and uses the same debug info that they use (?pdb?) -- that can
dynamically download symbol table mappings from MS and optionally
cache them locally.

Anyway, seems having a configurable limit might come in handy now and then?





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