Printing an uninitialized std::map results in an exception like "Cannot access memory at address 0x6c894ce02464895c" When calling -stack-list-locals and such an uninitialized std::map is in scope it fails with this exception. And this is not so good as there are no locals shown until the map is initialized. -stack-list-locals should catch python exceptions and return the error per variable. Same issue with -stack-list-arguments, -stack-list-variables and possibly other commands.
-var-update has the same issue.
This issue is really annoying (please read "pretty printers rule, just this small bug creates a problem redering them kind ob useless"). The typical C++ developer (including me) declares a variable when it is needed, not at the top of the function or method. So, with my Eclipse CDT patched to enable the pretty printers for the MI variable objects, and having code that often has local variables of types being associated with pretty printers, the variables view often remains empty until the end of the method. I have the impression that fixing this issue isn't possibly too complicated. Would it be possible to provide such a patch? This would help to continue with the work on Eclipse, and I could use the result for myself or anybody else who can use a patched gdb, at least. For Eclipse CDT, I tend to rate this bug as a blocking issue to really commit the support for the pretty printers (besides the value that is provided by - data-evaulate-expression), as there is no offical gdb version that would have fixed that bug, and without the fix, the IDE is not behaving usefully. This is to say, has this bug really "normal" severity?
(In reply to comment #2) I even tried to fix all my pretty printers to catch Exception, but it doesn't help, because the exception is not thrown in the pretty printer code, but when gdb uses the values that are returned by my iterator. Or is there any other workaround I could try in my pretty printers?
(In reply to comment #3) > Or is there any other workaround I could try in my pretty printers? You can omit the value, then you get all local variables again.
Does setting help maintenance set python print-stack off help in this circumstance?
(In reply to comment #5) > Does setting > help maintenance set python print-stack off > help in this circumstance? No. Here is what I get: 688,131 37-interpreter-exec console "maintenance set python print-stack off" 688,133 37^done 688,134 (gdb) 689,771 38-exec-next --thread 1 1 689,773 38^running 689,776 *running,thread-id="all" 689,776 (gdb) 689,779 *stopped,reason="end-stepping-range",frame= {addr="0x0000000000400fce",func="main",args=[],fi\ le="../src/sneha.cpp",fullname="/home/jelmenth/Projects/ws-dsf- test/sneha/src/sneha.cpp",line="60"},\ thread-id="1",stopped-threads="all",core="1" 689,779 (gdb) 689,821 39-stack-list-locals --thread 1 --frame 0 1 689,824 39^error,msg="Cannot access memory at address 0x64697469617700" 689,826 (gdb) 689,828 40-stack-info-depth --thread 1 5 689,829 40^done,depth="1" 689,830 (gdb)
Created attachment 4692 [details] Mi errors output I attached the output with the stack listing turned off? In this view you only see the locals output?
(In reply to comment #7) > Created an attachment (id=4692) > Mi errors output > I attached the output with the stack listing turned off? In this view you only > see the locals output? I your transaction an error happens, but -stack-list-locals nevertheless returns the locals, and I wouldn't have a real problem in my debugging session. I my case, -stack-list-locals does not return the locals at a all. Comparing your output and my output, the difference is the source of error. In your case an exception is thrown in the to_string method of the pretty printer. This seems to be handled properly. In my case the pretty printer methods don't throw. The error occurs later when gdb accesses one of the elements returned as children by the pretty printer.
I'm trying to create a case (via gdb -i=mi2) where I can replicate the crash when printing the child of value. print_string_repr (for to_string), and print_children (for children) do call gdbpy_print_stack which in turn calls PyErr_Print (). This prints the error and clears the exception. However if in GDB an python exception is not caught (or cleared as above) it will be converted to an internal GDB error() call which will terminate the current action GDB was working on. There is one case in print_children where gdbpy_print_stack is not called in a possible error condition (a child that is a string, but not a lazy string). But trying to produce a testcase is turning out to be a painful process. Do you have one handy that you could extract from your scenario?
Created attachment 4693 [details] my example Set the breakpoint to the top of main. When halted on the breakpoint, I hit normally hit the problem. Of course it depends on how unfortunate your uninitialized data currently looks, but I ran into the problem everytime. I use RedHad EL 5.3, gcc version 4.1.2 20080704 (Red Hat 4.1.2-44), a gdb 7.1 compiled from source, and the pretty printers from the latest STL applied to my STL
Thanks for the testcase! I've isolated the bug: 380 for (i = 0; i < options->print_max; ++i) (top-gdb) 382 PyObject *py_v, *item = PyIter_Next (iter); (top-gdb) std::map with 258866279488 elementsCannot access memory at address 0x18 Basically the Python iterator is failing (because the child is bogus/uninitialized). This happens in both mi and cli cases. A patch will be forthcoming.
Created attachment 4694 [details] patch Draft Patch
The problem I noted on my setup was common_val_print was raising a GDB error() due to a read at an invalid location. The function print_children() handles and clears its own Python exceptions, but this error() call was neither converted or handled. So this error was propagating as unhandled and the pretty printing process terminated in the command that called it. So commands like -stack-list-locals which print large amount of different variables were terminating prematurely. This draft patch in #12 fixes it for me, but I am not sure if it is correct. Does it work for you? I'd like Tom to have a look at this, hence the CC addition.
(In reply to comment #13) > Does it work for you? It definitely improves the situation. But I suspect there are other similar situations like the one you found and fixed. I still need to step over the declaration of map<int, string> mappedStrings; before local variables are returned.
The patch is not right. It is fixing the problem at a level that is "too low", it can happen with any error raised in these command, regardless whether that error emanates from python pretty printers. The python pretty printers just make this bug happen far more often. I'll look at fixing it universally in the value printing code.
Created attachment 4769 [details] non-python backtrace abort reproducer. Current output is: #3 0x4afe5437 in func () at dw2-loclist-prelinked.c:8 i = Could not find the frame base for "func". <backtrace stop> while we would expect output like: #3 0x4afe5437 in func () at dw2-loclist-prelinked.c:8 i = Could not find the frame base for "func". j = Could not find the frame base for "func". #4 ... continued backtrace Just the attached code is not suitable, it needs to be sanitized, but it proves the problem.
Hi, all. Is there any mechanism that in the debug build, the compiler can generate some extra code after a local variable is initialized. so that if we want to list the local variables, only the initialized variables will be shown. If I remember correct, In C++, if a function is invoked in the "try-exception" block, there will be a "local variable initialize list" for each function. So, when a exception happens, the function handling code must check this variable list, and see which variables were initialized, so that destructor functions will be called on these kind of objects. I'm not sure this special structure is exist in the "debug information". BTW: I have the python pretty printer enabled gdb, when debugging, I always get gdb crashed when I trying to view the uninitialized local variables. (Windows XP, and the gdb is built myself) IT is very important for an IDE like codeblocks. Asmwarrior ollydbg from codeblocks forum
Sorry for interrupt here again. I personally think that this "debug info about a variable is initialized or not" should exist in the function which exception handling is enabled. For example: Quote try { A a; CallXXX(); B b; CAllYYY(); } At this time, the variables info (initialed or not) should be recorded in somewhere. Because exceptions can happens every where, the exception handler need to call the "destruction of the already initialized objects". I guess there is a table to record this debug info.. So, my question is: Can GDB read this information? thanks.
The problem is not specific to Python, this can happen anywhere within GDB. Python is good at showing these bugs. There is, imo, a GDB exception not being handled correctly somewhere within the value printing code. It has to be caught and handled much closer to the exception source that my original patch (posted here). I'm working on a patch for this today, so hopefully we might see some relief from it soon.
Created attachment 4845 [details] another draft patch This patch assumes that apply_val_pretty_printer can raise errors. val_print is called most commonly in the pretty printers by print_children. This function makes n*children calls to PyIter, which usually results in errors arising from uninitialized data. These errors can come from *anywhere* within Python. If the exception is not handled here, it will bubble up to the top and GDB will stop executing. In this patch, I catch the exception and print the error and attempt to print out the data in raw format. I guess we could exit if we wanted to. This fixes the error cases in this bug. This is draft patch, what do you think?
(In reply to comment #20) > Created an attachment (id=4845) > another draft patch > > This patch assumes that apply_val_pretty_printer can raise errors. val_print > is called most commonly in the pretty printers by print_children. This > function makes n*children calls to PyIter, which usually results in errors > arising from uninitialized data. These errors can come from *anywhere* within > Python. If the exception is not handled here, it will bubble up to the top > and GDB will stop executing. In this patch, I catch the exception and print > the error and attempt to print out the data in raw format. I guess we could > exit if we wanted to. This fixes the error cases in this bug. This is draft > patch, what do you think? Thanks, I will test this patch as soon as I return to my work place. By the way, the way you use is try to catch all the exceptions from the python, this way, gdb are protected. But I'm not sure you have understand my post #18, I said that is there any "debug infor" that we can get, if one local variable has been initialized. There is a discussion at Codeblocks' forum http://forums.codeblocks.org/index.php/topic,12747.msg86349.html#msg86349 I have give an example, that if gcc can add some extra code to indicate that one local variable is initialized. Thanks Asmwarrior ollydbg from codeblocks' forum
(In reply to comment #20) > Created an attachment (id=4845) > another draft patch This is draft > patch, what do you think? Hi, I have just build a gdb.exe applied your patch, and it seems the gdb.exe still get crashed when I use "info local" command before some local variable declaration. So, My suggestion, I think gdb must understand which local variables were already initialized, and which are not. Then, "info local" command should only plot the initialized local variable. Thanks. asmwarrior
With the test-case posted here it works. If you can post me a test-case I will check against my build. I do not believe GDB can tell what is initialized and what is not. That might be another bug to file. But in the case here, GDB was missing exceptions generated and we catch them and deal with them in the pretty-printer case. It is beginning to sound like we have two bugs here.
I just re-read your comment and you noted GDB "crashed". That was never the behaviour before. GDB in this bug never crashes, but just stops supplying information for that command as a GDB exception was not caught. GDB was (And is, with my build) still alive and ready to receive other commands. What build/OS are you using?
(In reply to comment #23) > With the test-case posted here it works. If you can post me a test-case I will > check against my build. Hi,here is the test code: #include <string> #include <map> #include <list> #include <stack> #include <vector> void test() { std::string stdStr("std::string"); stdStr.append(" value"); std::map<int, std::string> m; m[0] = "000"; m[1] = "111"; std::string& stdStrRef = stdStr; stdStrRef += " Ref"; std::list<std::string> l = {"a", "b", "c"}; std::vector<std::string> v = {"a", "b", "c"}; std::stack<std::string> s; s.push("a"); s.push("b"); } int main() { test(); return 0; } In my system(WindowsXP, gdb build from MinGW 4.4.4, python pretty printer enabled) When I set a breakpoint before" std::string stdStr("std::string");", then entered the gdb command "info locals", then gdb crashed. Here is the log: Breakpoint 2, test () at E:\code\cb\codeblocks_test_code\gdbpython-demo\main.cpp:11 E:\code\cb\codeblocks_test_code\gdbpython-demo\main.cpp:11:111:beg:0x4013dc >>>>>>cb_gdb: > set debugevents off >>>>>>cb_gdb: > info locals stdStr = m = std::map with 4063232 elements<error applying pretty-printer>{ _M_t = { _M_impl = { <std::allocator<std::_Rb_tree_node<std::pair<int const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> = { <__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> = {<No data fields>}, <No data fields>}, members of std::_Rb_tree<int, std::pair<int const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<int const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<int>, std::allocator<std::pair<int const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_Rb_tree_impl<std::less<int>, false>: _M_key_compare = { <std::binary_function<int, int, bool>> = {<No data fields>}, <No data fields>}, _M_header = { _M_color = 4072408, _M_parent = 0x40a050, _M_left = 0x22fef0, _M_right = 0x77c2c024 }, _M_node_count = 4063232 } } } This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. > > I do not believe GDB can tell what is initialized and what is not. That might > be another bug to file. But in the case here, GDB was missing exceptions > generated and we catch them and deal with them in the pretty-printer case. > > It is beginning to sound like we have two bugs here.
Created attachment 4853 [details] Output from patch I get different results, GDB behaves as expected (Does not crash, abandons pretty printing for that local, prints the rest of the local out in raw format, moves onto the next local) I built your inferior with g++ -g3 -std=c++0x repr2.cpp -o repr2 I see over on the libstdc++ list there might be differences in your compiler. In any case, this looks like a mingw issue? Might need to split up this bug.
(In reply to comment #26) > Created an attachment (id=4853) > Output from patch > > I get different results, GDB behaves as expected (Does not crash, abandons > pretty printing for that local, prints the rest of the local out in raw format, > moves onto the next local) > > I built your inferior with > > g++ -g3 -std=c++0x repr2.cpp -o repr2 > > I see over on the libstdc++ list there might be differences in your compiler. > In any case, this looks like a mingw issue? Might need to split up this bug. Hi, thanks for your test. I found that if I set the breakpoint in the line 11, the same as you, then run info locals command gdb.exe( 20100613cvs ), works gdb.exe( 20100618cvs with your patch), gdb crash. But if I run "info locals" in very line of my code, none of gdb can survive. (Both of the gdb.exe will get crashes on some lines) As you said, GDB under Windows are not stable as on linux.
Hi, I would like to say something about the local variable. Today, I just read the Dwarf-2's standard PDF, http://dwarfstd.org/doc/dwarf-2.0.0.pdf then I found that for a local variable, it has a property named" scope". You can see it in the page 36 of that PDF. And in that page, there is an example code: float x = 99.99; int myfunc() { float f = x; float x = 88.99; return 0; } Then, the PDF said: ANSI-C scoping rules require that the value of the variable x assigned to the variable f in the initialization sequence is the value of the global variable x, rather than the local x,because the scope of the local variable x only starts after the full declarator for the local x. So, here comes my idea: If we breakpoint stops in the line: float f = x; That means, we are "out of the scope of local variable x". Can gdb find this property of the local x, at the same time, when people run: info locals command. GDB should firstly check all the locals, then only list the locals' scope is cover the current PC, by this, we can safely run the python script.(because all the variables involved must be initialized" already) I'm not sure you can understand my idea. Sorry, I'm not familiar with the source of GDB. Correct me if I'm totally wrong. Thanks Asmwarrior ollydbg from codeblocks' forum
A deeper search, I found that the DW_AT_start_scope information for a local variable was not emitted by GCC. So, GDB has no way to get these information. You can see http://gcc.gnu.org/ml/gcc/2007-04/msg00139.html I'm not sure it can be added in GCC easily. Asmwrrior
Some one from GCC maillist has suggestion me to use -fvar-tracking in the GCC command options, see http://gcc.gnu.org/ml/gcc/2010-06/msg00633.html From the GCC manual: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html -fvar-tracking Run variable tracking pass. It computes where variables are stored at each position in code. Better debugging information is then generated (if the debugging information format supports this information). It is enabled by default when compiling with optimization (-Os, -O, -O2, ...), debugging information (-g) and the debug info format supports it. So, is it possible that GDB get this information?
I'm not sure, but it is unlikely to get any traction or viewing here. This bug has been raised to deal with uncaught exceptions being generated because the data is uninitialized and the pretty-printers are not coping. While I don't necessarily disagree with anything you have proposed, I'm not likely the person to be involved in those deeper architectural changes ;) I purely hack on the Python aspects. The architectural changes you propose for GDB are unlikely to reach your target audience in the bug. I would try gdb@ mailing list.
@all I have solved "uninitialized local variable" problem by change the code of GDB source. You can see the screen shot of my result (I tested under Codeblocks WindowsXP) http://i683.photobucket.com/albums/vv194/ollydbg_cb/one_variable.png and http://i683.photobucket.com/albums/vv194/ollydbg_cb/two_variable-1.png I will soon publish my patch here.
Hi, here is my modified source code of gdb/stack.c it is around the line 1469, and then change the function to like this below: ------------------------- static void iterate_over_block_locals (struct block *b, iterate_over_block_arg_local_vars_cb cb, void *cb_data) { struct dict_iterator iter; struct symbol *sym; struct frame_info *frame; struct symtab_and_line sal; frame = get_selected_frame (NULL) ; find_frame_sal (frame, &sal); ALL_BLOCK_SYMBOLS (b, iter, sym) { switch (SYMBOL_CLASS (sym)) { case LOC_LOCAL: case LOC_REGISTER: case LOC_STATIC: case LOC_COMPUTED: if (SYMBOL_IS_ARGUMENT (sym)) break; if(sym->line>= sal.line) break; (*cb) (SYMBOL_PRINT_NAME (sym), sym, cb_data); break; default: /* Ignore symbols which are not locals. */ break; } } } --------------------------------- Asmwarrior ollydbg from codeblocks' forum
Please try to get a stack trace of gdb at the time of the crash. GDB should not crash in this circumstance. That is the bug here. I think all the stuff about scoping is a distraction; you can still see strange variable values due to bugs or whatnot; gdb has to be robust against that.
Subject: Bug 11407 CVSROOT: /cvs/src Module name: src Changes by: jkratoch@sourceware.org 2010-06-25 15:34:46 Modified files: gdb/testsuite : ChangeLog gdb/testsuite/gdb.dwarf2: dw2-ref-missing-frame-main.c dw2-ref-missing-frame.S dw2-ref-missing-frame.exp Added files: gdb/testsuite/gdb.dwarf2: dw2-ref-missing-frame-func.c Log message: gdb/testsuite/ Test PR python/11407. * gdb.dwarf2/dw2-ref-missing-frame-func.c: New file. * gdb.dwarf2/dw2-ref-missing-frame.S: Use cu_text_start and cu_text_end. Split main into func_nofb and func_loopfb dropping NO_FRAME_BASE. * gdb.dwarf2/dw2-ref-missing-frame.exp: Remove variables sources, executable_nofb and executable_fb. New variables srcsfile, objsfile, srcfuncfile, objfuncfile, srcmainfile, objmainfile, executable and binfile. Call gdb_compile with clean_restart twice. (func_nofb print, func_nofb backtrace, func_loopfb print) (func_loopfb backtrace): New. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2350&r2=1.2351 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame-func.c.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame-main.c.diff?cvsroot=src&r1=1.1&r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame.S.diff?cvsroot=src&r1=1.2&r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame.exp.diff?cvsroot=src&r1=1.4&r2=1.5
A patch was posted for the CLI interpretation of the bug here: http://sourceware.org/ml/gdb-cvs/2010-06/msg00169.html A patch for MI is currently being discussed here. Here is the latest rendition of tha patch: http://sourceware.org/ml/gdb-patches/2010-06/msg00599.html Assigned this bug to MI component.
Subject: Bug 11407 CVSROOT: /cvs/src Module name: src Changes by: pmuldoon@sourceware.org 2010-09-16 13:47:55 Modified files: gdb : ChangeLog gdb/mi : mi-cmd-stack.c gdb/testsuite : ChangeLog Added files: gdb/testsuite/gdb.mi: dw2-ref-missing-frame-func.c dw2-ref-missing-frame-main.c dw2-ref-missing-frame.S dw2-ref-missing-frame.exp Log message: 2010-09-16 Phil Muldoon <pmuldoon@redhat.com> PR mi/11407 * mi/mi-cmd-stack.c (list_args_or_locals): Catch exceptions from read_var_value and common_val_print and print a warning. 2010-09-16 Phil Muldoon <pmuldoon@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> PR mi/11407 * gdb.mi/dw2-ref-missing-frame-func.c: New File. * gdb.mi/dw2-ref-missing-frame-main.c New File. * gdb.mi/dw2-ref-missing-frame.S New File. * gdb.mi/dw2-ref-missing-frame.exp New File. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.12189&r2=1.12190 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/mi/mi-cmd-stack.c.diff?cvsroot=src&r1=1.51&r2=1.52 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2449&r2=1.2450 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame-func.c.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame-main.c.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame.S.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame.exp.diff?cvsroot=src&r1=NONE&r2=1.1
MI fix checked in as per comment #37. Thanks for your patience!
Set Target to 7.3
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.