Error in `/tmp/Main': free(): invalid next size (fast): No dynamic allocation

Question

So, I'm doing a problem called "Unique Paths II" in lintcode. However, I encountered a runtime error during a testcase:

// in the context, map is the 2d array that saves the obstacle path as described in the question, which fits common code practices
    for (int i = 1; i < n; i++) {
        if (map[0][i] != 1)
        map[0][i] = 1;
        else{
            for(;i<m;i++){
                map[0][i] = 0;
            }
            break;
        }
    }

Lintcode gives me this error:

*** Error in `/tmp/Main': free(): invalid next size (fast): 0x0000000001bb5130 *** ======= Backtrace: ========= [0x625861] [0x62dda6] [0x631dd7] [0x40f00a] [0x40c78e] [0x409cda] [0x407823] [0x4062a7] [0x410cd9] [0x40e361] [0x40bbb0] [0x40912d] [0x406ca1] [0x405b96] [0x4031ce] [0x6038c6] [0x603aba] [0x400d69] ======= Memory map: ======== 00400000-007d9000 r-xp 00000000 ca:01 890688 /tmp/Main 009d8000-009e4000 rw-p 003d8000 ca:01 890688 /tmp/Main 009e4000-009e9000 rw-p 00000000 00:00 0 01b92000-01bd6000 rw-p 00000000 00:00 0 [heap] 7f5660000000-7f5660047000 rw-p 00000000 00:00 0 7f5660047000-7f5664000000 ---p 00000000 00:00 0 7f5666690000-7f5666691000 rw-p 00000000 00:00 0 7ffea1f83000-7ffea1fa4000 rw-p 00000000 00:00 0 [stack] 7ffea1ff0000-7ffea1ff3000 r--p 00000000 00:00 0 [vvar] 7ffea1ff3000-7ffea1ff5000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped)

What is wrong here?

Please provide a [mcve]. Can you reproduce the problem on your machine? A core was dumped. Did you analyze it? — Thomas Sablik, Sep 12 '19 at 14:13
@molbdnilo No it doesn't. I can only codesign and use gdb 8.0.1 which can't read a clang symbol. — , Sep 12 '19 at 14:25
I don't know if this counts, but whenever you paste the above code into lintcode's editor for the problem, it reports a running error on this testcase. — , Sep 12 '19 at 14:34
Your example should be compilable. My compiler does not compile without `main` function — Thomas Sablik, Sep 12 '19 at 14:36
You marked the error at the wrong place. The function is completely run through and reaches the return statement. The error occurs in the destructor of `map`. — Thomas Sablik, Sep 12 '19 at 14:44
Note that the crash site is rarely the location of the bug that caused the crash. The error message is a common result of something damaging the control information for a dynamic allocation, often by writing out of bounds. `vector` is a wrapper around a ball of dynamic memory. If one toolchain can't find a bug, drop the code into another and keep looking. Mac has a lot of good development tools. — user4581301, Sep 12 '19 at 15:02
Suggestion: Temporarily replace use of the `[]` operator with calls to the `at` function. `at` performs a bounds check, helping you find or eliminate as a potential cause of error out of bounds accesses of the `vector`s. Mac has some excellent programming tools. — user4581301, Sep 12 '19 at 15:02
@user4581301 I pretty much agree that mac has excellent programming tools. But notice I said "pretty much". Valgrind doesn't work, gdb doesn't work, dr.memory doesn't work, etc. — , Sep 13 '19 at 00:53
That is unfortunate. Valgrind is a very effective tool. GDB not working surprises me greatly. How about lldb? — user4581301, Sep 13 '19 at 02:57
lldb isn't as great as gdb, such as I can't analyze the core, I can't view expression values, and I can't view 2d naked arrays. Other than that it's good. — , Sep 13 '19 at 04:44

Thomas Sablik · Accepted Answer · 2019-09-12T16:13:37.427

0

Regardless of the error you should read Why is “using namespace std;” considered bad practice? and enable compiler warnings. In your code are many

warning: implicit conversion changes signedness: 'int' to 'size_type' (aka 'unsigned long') [-Wsign-conversion]

and

warning: implicit conversion loses integer precision: 'size_type' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]

You could easily fix it with

auto m = map.size(), n = map[0].size();

and

for (decltype(n) i = 1; i < n; i++) {

You can use lldb to debug code compiled with clang.

The actual error is in the section

for (int i = 1; i < n; i++) {
    if (map[0][i] != 1)
    map[0][i] = 1;
    else{
        for(;i<m;i++){
            map[0][i] = 0;
        }
        break;
    }
}

In the outer loop i iterates from 0 to n but in the inner loop i iterates from 0 to m and

map[0][i]

goes out of bounds.

edited Sep 12 '19 at 16:13

answered Sep 12 '19 at 15:56

Thomas Sablik

16,127
7
34
62

Before I test your answer I just want to say that lintcode includes all libraries and uses std by default. So I don't need to read that unless I have a function of a similar name. – Sep 13 '19 at 00:51
Then you shouldn't program there. You get used to very bad code style, have no compiler warnings and can't debug your code. – Thomas Sablik Sep 13 '19 at 06:44
`You get used to very bad code style, have no compiler warnings` I can test in eclipse before I submit in lintcode. When in eclipse I do not use std. The only difference when I'm copy-pasting my solution is that I remove all the `std::` definitions. Those errors can be seen in the console `can't debug your code` Heard of `lldb-mi` ? – Sep 13 '19 at 13:07
As we can see in your question you did not fix the warnings and are used to very bad code style. You was not able to debug your code and find your problem. Your initial problem confirms that my criticism is justified. Of course you know that you could do it better, but you didn't and you wasn't able to. – Thomas Sablik Sep 13 '19 at 13:46

Error in `/tmp/Main': free(): invalid next size (fast): No dynamic allocation

1 Answers1