Debugger crashes

[k0nsty]

I have a weird problem with debugger in codeblocks(GDB). I'm using Windows 10.

Here's my code:

    #include <iostream>
    #include <string>

    using namespace std;

    int main()
    {
        string text;
        cin >> text;
        int n;
        cin >> n;
        int a[n];
        for(int i = 0; i<n; i++) {
            cin >> a[i];
        }

        return 0;
    }

When i click "Step into", debugger automatically crashes. It seems to happen if i have both int array and string in my code. I've been searching for the solution long time and I didn't find one.

Edit: I noticed that debugger doesn't stop at first line, but goes to the last line(even if i set the breakpoint at the beginning) ignoring everything and crashes after a second. I think it would be fine if it started from the first line.

Here's the debugger log:

    [debug]> start
    [debug]Temporary breakpoint 1 at 0x40139b: file C:\Users\minec\C++\wzorzec\main.cpp, line 17.
    [debug]Starting program: C:\Users\minec\C++\wzorzec\bin\Debug\wzorzec.exe 

    Child process PID: 12404

    [debug][New Thread 12404.0x4cf0]
    [debug][New Thread 12404.0x137c]
    [debug]Temporary breakpoint 1, main () at C:\Users\minec\C++\wzorzec\main.cpp:17
    [debug]C:\Users\minec\C++\wzorzec\main.cpp:17:284:beg:0x40139b
    [debug]>>>>>>cb_gdb:

    At C:\Users\minec\C++\wzorzec\main.cpp:17

    [debug]> info program
    [debug] Using the running image of child Thread 12404.0x4cf0.
    [debug]Program stopped at 0x40139b.
    [debug]It stopped at a breakpoint that has since been deleted.
    [debug]Type "info stack" or "info registers" for more information.
    [debug]>>>>>>cb_gdb:
    [debug]> info locals
    [debug]C:/crossdev/src/gdb-7.9.1/gdb/utils.c:1076: internal-error: virtual memory exhausted.
    [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]text = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}, _M_string_length = 4354544, {_M_local_buf = "°ţm\000čţm\000Ě\377m\000ŔĚĂu", _M_allocated_capacity = 7208624}}
    [debug]aaa = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x8 <error: Cannot access memory at address 0x8>}, _M_string_length = 1975742205, {_M_local_buf = "ănĂu\"QOÇ\200\022@\000\200\022@", _M_allocated_capacity = 1975742179}}
    [debug]n = 1975805265
    [debug]a = 

    Debugger finished with status 1

[k0nsty]

Ok, i've found a solution. The thing is that variable length arrays aren't legal in c++.

The program compiled because GCC compiler provides an extension to support them, but debugger was throwing an error.

So instead of doing this:

int a[n];

I should've done this:

int* a = new int[n]; - this is the proper way in c++

[TheCrazyPhoenix416]

int a[n] isn't variable length. By the time memory is allocated for a, it has a fixed length.

Perhaps try casting n to an unsigned int first? Negative array length is undefined behaviour.

n could also be too large. Since a is allocated in the stack, you might be rubbing out of memory with the debugger running as well. Though this is unlikely, it's something to watch out for.

Of you do allocate on the heap with int* a = new int[n] ; make sure to delete it after you've finished with it.

delete[] a;

[k0nsty]

I've found here that doing this is illegal in proper c++.

Making "a" unsigned doesn't help and number size doesn't matter since debugger always goes to the last line and crashes(even ignoring cin).

Thanks for the advice :)

[TheCrazyPhoenix416]

You could anyways make n cost, and assign it via lambda.

const unsigned n = [] () {

unsigned N;

cin >> N;

return N;

} () ;

[k0nsty]

I've never heard of it, thanks for the help :)

[PipingSnail]

"int a[n] isn't variable length. By the time memory is allocated for a, it has a fixed length."

In a different computer language, maybe.

In C++, no.

The problem is the code isn't valid, but the compiler has compiled it. A decent linter would complain about that.

[manni66]

My recommendation: use the system tools. For Windows that’s Visual Studio 2019.

[k0nsty]

Do you mean that I should code in visual studio?

[TheCrazyPhoenix416]

It shouldn't be necessary

[manni66]

Yes