CODEWITHSUNDEEP
c++stringgdb
fdf fdf
fdf fdf

Reputation: 43

is it a gdb bug?

 1 #include "string"
 2 using namespace std;
 3 
 4 bool m_bInited = true;
 5 int  m_imaxsize = 100;
 6 
 7 int test()
 8 {
 9     if (!m_bInited)
10     {
11         return -1;
12     }
13 
14     std::string gbkInput = "";
15     std::string utf8Input = "";
16     if (gbkInput.size() > m_imaxsize)
17     {
18         return 1;
19     }
20     return 0;
21 }
22 
23 int main()
24 {
25     test();
26     return 0;
27 }

when using gdb step from line 16, the debug sequence is:

line 16 -> line 20 -> line 18 -> line 21. 

    (gdb) b 16
    (gdb) r
    Breakpoint 1, test () at main.cpp:16
    16          if (gbkInput.size() > m_imaxsize)
    (gdb) n
    20          return 0;
    (gdb) n
    18              return 1;
    (gdb) n
    21      }

compile: g++ -g main.cpp -o test

why gdb display line 18 ? and the test() return value is 0.

my gcc version is 4.1.2. GNU gdb Fedora (6.8-37.el5) or GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5) . Both gdb version has this problem.

BTW: if move line 14,line 15 (these 2 string var) to line 9, it will be ok. gdb will not display line 18 ! it seemed the string var cause this bug.

Can everyone help me? Thank you!

Upvotes: 4

Views: 435

Answers (1)

David Hammen
David Hammen

Reputation: 33116

This behavior is a "feature" of older versions of gcc/gdb, and it's been reported here before: gdb unexpected behavior: in nested if. Note: This question can't be marked as a duplicate of that other as there was no satisfactory solution.

The statement isn't being executed. It just looks like it.

Addendum
It's easy to verify that the statement is not being executed. Add a function

int one() {
   return 1;
}

Then replace that return 1; with return one(); gdb will print return one(); but it does not call the function one(). Apparently there's a problem in older versions of gdb with displaying the execution of the close brace on an if statement.

Note well: This only happens with older versions of gdb, and it's apparently a problem of display rather than of incorrect program execution.

Upvotes: 4

Related Questions