Created attachment 6537 [details] vector gdb frozen Having an unitialized std::vector gdb freezes and doesn't respond anyway. Especially when you call -var-list-children in the line where std::vector is still uninitialized. Example: Code GDB ------------------------------------------------------------------------------ std::vector<int> vec; << -var-create - * vec << -var-list-children var1 vec.push_back(1); ------------------------------------------------------------------------------- Within Eclipse CDT they must have some implementation that debugging is still available.
First, I agree it would be good to be able to interrupt gdb when it gets wedged like this. However, the problem here is that the varobj has many children -- in my test, 105312 of them (but obviously YMMV). Front ends are supposed to limit dynamic varobj output using the provided controls, like -var-set-update-range or the optional arguments to -var-list-children. Otherwise, bad things will happen. In this case, the vector is uninitialized, causing problems. But the same problems can occur due to other bugs in the program (trashing the heap), or just if the program happens to create a really huge data structure -- not unheard-of.
I agree to you that it is better to set an update range, also for the other cases you mentioned. However is there no possibility to check if the variable is unitialized, or do you know if a feature like that will be implemented in future? Eventually from gcc perspective.
(In reply to comment #2) > I agree to you that it is better to set an update range, also for the other > cases you mentioned. However is there no possibility to check if the variable > is unitialized, or do you know if a feature like that will be implemented in > future? Eventually from gcc perspective. It may be possible to do this in gcc -- there was one attempt already, see DW_OP_GNU_uninit -- but I think it is not a good approach, for the reasons already outlined.
I'm going to mark this one as not a bug. There isn't much gdb can or should do about uninitialized memory. Front ends can limit the number of varobj children, and should do so for exactly this reason.