This is the mail archive of the
mailing list for the Cygwin project.
Re: Configurable stack trace please
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
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
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
But this was a longer trace for syslogd's main thread.
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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple