Debugger in C::B. Can't open cygwin.S

Question

Hi I just discovered a quite weird behaviour of the debugger when declaring a simple two-dimensional array. It looks like it can't open a file cygwin.S in the library.

Cannot open file: ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S

At ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S:169

An execution without debugging works fine. There is an example of the code:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    const int strNumTries = 15;
    const int strLength = 98;
    char strName[strLength][strNumTries];

    printf("Hello world!\n");

    return 0;
}

Debugger stops on the char array declaration using 'step in' method. So what's the problem it may be?

Answer 1

I received this error when i was trying to debug using gdb in vscode. Vscode don't offer redirected input especially for C. So i was using freopen(). Everything worked fine until it stepped into the declaration part of array.

int arr[n]

So I replaced it with a pointer and allocated memory dynamically.

int *arr=(int *) malloc(sizeof(int)*n);

and this worked.

I think gdb is unable to handle those arr[variable] declaration. But I may be completely wrong. Hope this helps.

Answer 2

Not sure if this will help your situation, but ...

I had exactly the same errors from GDB, and GDB admitted it had failed and had a problem (see GDB listing below). I could reproduce this with GCC/gFortran 6.4 and 7.1 100% (running C::B under Win, with MingW).

Of course, I had not ever installed cygwin, and I only use seh and sjlj variants of the MingW64 compilers. Also, I don't have, and never had any of the dir's that GDB is complaining about (e.g. "/../src/gcc-7.1.0/") so it made no sense ... and the problem arose only after adding one more ostensibly similar s/r to my lib of thousands of s/r's (none of which ever complained about this).

... to make a long story short, the problem turned out to be "out of stack space", as I had declared some (Automatic) arrays with large size. Changing either the array sizes (smaller) or changing the Automatic arrays to Allocatable arrays (the former goes on the stack, the later on the heap) fixed the problem.

... so, GDB seems to have a bug, and its complaints had nothing to do with the actual error.

---- for completeness, here is the relevant portion of my GDB listing:

[debug][New Thread 740.0x9fc]
[debug]172      ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S: No such file or directory.
[debug]Thread 1 received signal SIGSEGV, Segmentation fault.
[debug]__chkstk_ms () at ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]Stack level 0, frame at 0x136f00:
[debug] eip = 0x664974bb in __chkstk_ms (../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172); saved eip = 0x664958b3
[debug] called by frame at 0x136f14
[debug] source language asm.
[debug] Arglist at 0x136ef8, args:
[debug] Locals at 0x136ef8, Previous frame's sp is 0x136f00
[debug] Saved registers:
[debug]  eax at 0x136ef4, ecx at 0x136ef8, eip at 0x136efc
[debug]>>>>>>cb_gdb:

Cannot open file: ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S
At ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172

[debug]> info locals
[debug]No locals.
[debug]>>>>>>cb_gdb:
[debug]> info args
[debug]No symbol table info available.
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]../../../../src/gdb-7.11.1/gdb/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion `framefunc != NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it.  For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.
[debug]#0  __chkstk_ms () at ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172
[debug]#1  0x664958b3 in fadcern_sixtrack_xl (

Debugger finished with status 1

Answer 3

I suspect your seeing something like this:

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from untitled...done.
(gdb) br main
Breakpoint 1 at 0x4005f1: file untitled.c, line 6.
(gdb) r
Starting program: /home/xxxx/untitled 
.
.
.

Breakpoint 1, main () at untitled.c:6
6       const int strNumTries = 15;
(gdb) s
7       const int strLength = 98;
(gdb) 
8       char strName[strLength][strNumTries];
(gdb) 
10      printf("Hello world!\n");
(gdb) 
_IO_puts (str=0x400794 "Hello world!") at ioputs.c:34
34  ioputs.c: No such file or directory.
(gdb) 
36  in ioputs.c
(gdb) 
strlen () at ../sysdeps/x86_64/strlen.S:66
66  ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) 
67  in ../sysdeps/x86_64/strlen.S
(gdb) 
68  in ../sysdeps/x86_64/strlen.S

where that last line repeats many times before moving on to any other sub functions.

This is not an error, but rather part of the call to printf()

the following is the only gdb output that has anything to do with the array declaration:

8       char strName[strLength][strNumTries];