User forums > Using Code::Blocks

see content of a vector in debugging

<< < (23/26) > >>

oBFusCATed:
Great, thank you for the time too :)

Next step in my TODO (not a real todo list thought) for the debugger is  to find why it is so slow.
I've some clues and I've found some hot spots (fixed one in a previous post in this thread).
Should I start a new thread or to post here?

p.s. I'll test it myself when it reaches the wxaui branch

ollydbg:
Hi all.

Seems there is a bug, a function name will be recognized as a vector name. See the screen shot:

oBFusCATed:
OK, here is a little patch


--- Code: ---Index: src/scripts/gdb_types.script
===================================================================
--- src/scripts/gdb_types.script        (revision 5731)
+++ src/scripts/gdb_types.script        (working copy)
@@ -164,9 +164,12 @@
     local element_type_value = vector_info_str.Mid(capacity_end_pos + 15,
                                                    vector_info_str.length() - capacity_end_pos - 15);
 
-    local result = _T("[size] = ") + size_value + _T("\n");
-    result += _T("[capacity] = ") + capacity_value + _T("\n");
-    result += _T("[element type] = ") + element_type_value + _T("\n");
+    local result = _T("[size] = ") + size_value + _T(",\n");
+    result += _T("[capacity] = ") + capacity_value + _T(",\n");
+    result += _T("[element type] = ") + element_type_value;
+
+    if(size > 0)
+        result += _T(",\n");
 
     local value_str = a_str;
     for(local item = 0; item < size; item += 1)
@@ -185,8 +188,12 @@
             local equal_pos = elem_value.Find(_T(" = "));
             if(equal_pos >= 0)
                 elem_value.Remove(0, equal_pos + 3);
+            if(item > 0)
+                result += _T(",");
             result += _T("[") + item + _T("] = ") + elem_value + _T("\n");
         }
+        else
+            break;
 
         value_str.Remove(0, elem_end);
     }


--- End code ---

It does two things:
1. Add , at the end of every item/line, so the output more like the one emitted from GDB (not readly needed in trunk, but in my local patch)
2. Fixes an almost infinite loop if the vector is not initialized.


--- Code: ---
     std::vector<int> v; // <- if you break here and add v to the watches, C::B freezes, because vector.size is very big number (in my case, but it could be anything)
     v.push_back(1);

--- End code ---


Best regards...

killerbot:

--- Quote ---std::vector<int> v; // <- if you break here and add v to the watches, C::B freezes, because vector.size is very big number (in my case, but it could be anything)
--- End quote ---

the vector size should be 0, according to the standard, right ?

oBFusCATed:
If you break on the next line, yes, the size should be 0...
But on the first line the c-tor have not run and the pvector command calculates the size incorrectly... don't know exactly why... 8)

Navigation

[0] Message Index

[#] Next page

[*] Previous page