This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [python] update has_more generation


On Saturday 05 September 2009 Tom Tromey wrote:

> Volodya> There's another issue I've run into. I had:
> Volodya>     std::vector<std::string> v2;
> Volodya> I've set breakpoint on this line, and when breakpoint was hit,
> Volodya> tried to examine v2. GDB said it has >0 elemens (because v2 is
> Volodya> not initialized yet), and then failed to pretty-print the
> Volodya> requested members, and did "raw" pretty printing.  Is this
> Volodya> expected?
> 
> Nope.
> 
> I tried this simpler example:
> 
>     #include <vector>
>     #include <string>
> 
>     int main(int ac, char* av[])
>     {
>         std::vector<std::string> v2;
>         v2.push_back("hi");
>         v2.push_back("there");
>         return 0;
>     }
> 
> I was able to reproduce the problem with an older version of the
> libstdc++ printers.
> 
> The underlying problem I saw was that the type of the string was
> std::basic_string<char>, but the regexp looked like:
> 
>     pretty_printers_dict[re.compile('^std::basic_string<char,.*>$')] = lambda val: StdStringPrinter('@target-charset', val)
> 
> I removed that "," from gcc trunk a while ago.
> 
> Could this be the problem you are seeing?

I definitely have up-to-date pretty-printers, so the problem is different. I imagine
I get to debug this on my end, which I'll do tomorrow. (This probably should
not prevent any merge, and nothing crashes, just gets somewhat wrong data where
no valid data exists anyway)
 
> Volodya> (gdb) -var-update --all-values *
> Volodya> ^done,changelist=[{name="var0",value="{...}",in_scope="true",type_changed="false",new_num_children="2",displayhint="array",has_more="0"}]
> Volodya> And this point the vector has 2 elements, which is right. But
> Volodya> it does not report any change, so the above scary row value is
> Volodya> still displyed. Creating new varobj does show right string
> Volodya> values.
> 
> I couldn't reproduce this, I get:
> 
> ^done,changelist=[{name="v2",value="{...}",in_scope="true",type_changed="false",new_num_children="1",displayhint="array",has_more="0",new_children=[{name="v2.[0]",exp="[0]",numchild="0",value="\"hi\"",type="std::basic_string<char>",thread-id="1"}]}]

I imagine that the reason you cannot reproduce this is that you cannot reproduce the previous problem.

> 
> 
> I'm using this MI input:
> 
>     -enable-pretty-printing
>     python execfile('/home/tromey/gnu/Trunk/trunk/libstdc++-v3/python/libstdcxx/v6/printers.py')
>     python register_libstdcxx_printers(None)
>     break main
>     run
>     -var-create v2 * v2
>     -var-list-children v2 0 50
>     -exec-next
>     -var-update --all-values v2
>     -exec-next
>     -var-update --all-values v2
> 
> Volodya> (gdb) -var-list-children --all-values "var1" 0 5
> Volodya> Traceback (most recent call last):
> Volodya> File "/home/ghost/Build/python/libstdcxx/v6/printers.py", line 469, in to_string
> Volodya> return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
> Volodya> RuntimeError: Cannot access memory at address 0x1fa
> 
> I also get these tracebacks.
> 
> We're probably going to need smarter error handling somewhere.

Beside, that 'length = len' is also risky -- it means that if the string is not initialized,
we might end up reading a lot of memory.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]