Stack trace question

Stack trace question

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

Hi all,

I have the following stack trace (64 bit Cygwin app), and I can't figure how the same frame RBP at 000FFFFC7B0 can be listed 3 consecutive times for various functions (RIPs).  Also if I follow the stack trace with gdb (and the trace is all within Cygwin.dll based at 180040000), it does not make any sense (it was a simple abort() in the application due to some external condition; no segfault or any other nasty kind of stuff)...  The program does not use SYSV IPC at all (so the appearance of shmat() is highly suspicious).

Can there be something wrong as to how the stack trace gets generated?

Any insight will be highly appreciated.

Thanks,
Anton

P.S. I know it's a bit old Cygwin but source and binaries are all consistent.

Stack trace:
Frame        Function    Args
000FFFFC090  0018005D20C (000FFFFE3F4, 00000000000, 000FFFFC118, 000FFFFDE50)
000FFFFC130  0018005E81B (00000000064, 00000000000, 00000000154, 00000000000)
000FFFFC380  001801211AD (00000000001, 000FFFFC530, 000FFFFD680, 000FFFFC680)
000FFFFC670  0018011DB41 (000FFFFC560, 00000000000, 00000000000, 0018013F911)
000FFFFC7B0  0018011DFE9 (001800F19E0, 00000000000, 001004E4A3B, 00000000006)
000FFFFC7B0  0018011E1BA (001004DB1BB, 001004DA95A, 000FFFFCDF0, 000FFFFC7B0)
000FFFFC7B0  0018011E47F (00000001000, 00000000000, 001004E4A3B, 001004E2516)

(gdb) info line *0x0018005D20C
Line 980 of "/usr/src/debug/cygwin-2.11.2-1/winsup/cygwin/environ.cc"
   starts at address 0x18005d1ea <spenv::retrieve(bool, char const*)+538>
   and ends at 0x18005d223 <spenv::retrieve(bool, char const*)+595>.
(gdb) info line *0x0018005E81B
Line 1153 of "/usr/src/debug/cygwin-2.11.2-1/winsup/cygwin/exceptions.cc" starts at address 0x18005e80f <ctrl_c_handler(DWORD)+111>
   and ends at 0x18005e820 <ctrl_c_handler(DWORD)+128>.
(gdb) info line *0x001801211AD
Line 9718 of "sigfe.s" starts at address 0x1801211a9 <_sigfe_vswprintf+9> and ends at 0x1801211ae <_sigfe_vswscanf>.
(gdb) info line *0x0018011DB41
Line 226 of "/usr/src/debug/cygwin-2.11.2-1/winsup/cygwin/shm.cc" starts at address 0x18011db23 <shmat(int, void const*, int)+675>
   and ends at 0x18011db67 <shmat(int, void const*, int)+743>.
(gdb) info line *0x0018011DFE9
Line 130 of "sigfe.s" starts at address 0x18011dfe6 <sigdelayed+225> and ends at 0x18011dfee <sigdelayed+233>.
(gdb) info line *0x0018011E1BA
Line 276 of "sigfe.s" starts at address 0x18011e1b5 <sigsetjmp+15> and ends at 0x18011e1bc <sigsetjmp+22>.
(gdb) info line *0x0018011E47F
Line 632 of "sigfe.s" starts at address 0x18011e47d <_sigfe___res_nsearch+9> and ends at 0x18011e482 <_sigfe___res_nsend>.


--
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: Stack trace question

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Nov  8 05:55, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Hi all,
> 
> I have the following stack trace (64 bit Cygwin app), and I can't
> figure how the same frame RBP at 000FFFFC7B0 can be listed 3
> consecutive times for various functions (RIPs).

The functions in question are signal handling stuff, partially written in
assembler.  They don't change $rbp at all.

> Also if I follow the
> stack trace with gdb (and the trace is all within Cygwin.dll based at
> 180040000), it does not make any sense (it was a simple abort() in the
> application due to some external condition; no segfault or any other
> nasty kind of stuff)...  The program does not use SYSV IPC at all (so
> the appearance of shmat() is highly suspicious).
> 
> Can there be something wrong as to how the stack trace gets generated?

If so, I'm not aware of that.  Cygwin uses the ntdll RtlVirtualUnwind and
RtlLookupFunctionEntry functions on 64 bit to iterate over the stack.

One problem in your stackdump may be that, apparently, a longjmp has
been performed (sigsetjmp is on the stack which is weird anyway).  Stuff
like that *may* indicate that the stack is broken.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]