I have enabled the python pretty printers for varobjs (-var-enable-pretty- printing in the beginning of the MI session). If running into breakpoints at the first line of a method that contains local variables of a non-trivial type, I run into all types of errors, ranging from python exceptions to "Cannot access memory at address ...". The reason is that their constructor is called in a soure line behind the breakpoint, such that data members are not yet initialized. In many cases (consider a collection with pointer members "start" and "end"), a large amount of garbage data is read (unnecessary response time), that might even be unaccessible (unnecessary errors). My gdb frontend (Eclipse DSF GDB) does not actually crash or hang. It's just that running the python pretty printer on tons of unitiliazed data with all those errors really is a usability problem for frontends that use the varobjs. I don't think the writers of a python pretty printer have the chance to workaround, nor do I think they should. I know the argument that the pretty printer also has to work in case of a programming error in C/C++ code. But I don't think a user should suffer is debugged code as well as the provided pretty printers are clean. As far I as know, the debug info generated by gcc provides the information in which line a local variable is constructed.
We changed how errors are propagated from printers to varobj, which should help this problem a bit -- you should get a more sensible display from properly written printers. Could you try this? FWIW, I think trying to circumvent pretty-printing based on checking line numbers to see if initialization has occurred is likely to be fragile. First, in the presence of optimization, this information is not really reliable. Second, the same effect can be seen via data corruption anyway -- so it is better instead to try to come up with a solution that is robust in the presence of errors.
(In reply to comment #1) > We changed how errors are propagated from printers to varobj, > which should help this problem a bit -- you should get a more > sensible display from properly written printers. > Could you try this? Yes, I just installed gdb 7.3.1 and will use it the next days. > FWIW, I think trying to circumvent pretty-printing based on > checking line numbers to see if initialization has occurred is > likely to be fragile. First, in the presence of optimization, > this information is not really reliable. Second, the same effect > can be seen via data corruption anyway -- so it is better instead > to try to come up with a solution that is robust in the presence > of errors. You are possibly right, relying on the line numbers will not really improve robustness. I'm fine if you close this bug. There or other bugzillas to address individual stability problems with one or the other command. In the case they are missing, I will formulate them under the assumption that pretty printing must never make gdb crash or hang, even if the pretty printer developer did a mistake.
Hi, Jens, I have a word around to filter out the local variables by compare the current line and the declaration line of the local variable. see: http://sourceware.org/bugzilla/show_bug.cgi?id=12127
Comparing lines doesn't really work with optimizations. There's not really a good way to handle this problem. We've left it up to the printers but perhaps throwing a memory exception could propagate to gdb, and it could do something smarter. Though of course printers can catch that and still behave badly.
*** Bug 22487 has been marked as a duplicate of this bug. ***
*** Bug 21208 has been marked as a duplicate of this bug. ***
*** Bug 12555 has been marked as a duplicate of this bug. ***