Summary: | gdb with python support still get crash on showing uninitialized local variables | ||
---|---|---|---|
Product: | gdb | Reporter: | asmwarrior <asmwarrior> |
Component: | python | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | asmwarrior, ssbssa, tromey, xdje42, xunxun1982 |
Priority: | P2 | ||
Version: | 7.0 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | gdb log about the crash |
Description
asmwarrior
2010-10-16 01:13:34 UTC
I have some work around patches to filter out the uninitialized local variables by compare the current instruction line and the declaration line of the variable. Thus avoid the crash. See: http://sourceware.org/ml/gdb-patches/2011-12/msg00034.html Created attachment 7017 [details]
gdb log about the crash
Today, I managed to find one crash problem. See the debug log (crash.txt) as attachment. I use the same sample program to create a "a1.exe", then one debugger_gdb to start a debugee_gdb, then let the debugee_gdb to load stlc++ python script, then a1.exe was loaded in debugee_gdb, and I can make debugee_gdb crash when simply type "p v" command (At the time v is a std::vector auto variable which was not initialized). Look at the bt, you can see that gdb (in apply_val_pretty_printer function call) try to malloc a big buffer which size is 2009291924. (gdb) up #4 0x0046ecfe in print_string_repr (printer=0x31075f8, hint=0x58a91e8 "string", stream=0x2ec2f68, recurse=1, options=0x298f9d4, language=0x7ee360 <cplus_language_defn>, gdbarch=0x2ebd520) at ../../gdb/gdb/python/py-prettyprint.c:336 336 val_print_string (type, encoding, addr, (int) length, (gdb) l 331 make_cleanup (free_current_contents, &encoding); 332 gdbpy_extract_lazy_string (py_str, &addr, &type, 333 &length, &encoding); 334 335 local_opts.addressprint = 0; 336 val_print_string (type, encoding, addr, (int) length, 337 stream, &local_opts); 338 } 339 else 340 { (gdb) p length $9 = 2009291924 (gdb) p local_opts $10 = {pretty = Val_pretty_default, prettyprint_arrays = 0, prettyprint_structs = 0, vtblprint = 0, unionprint = 1, addressprint = 0, objectprint = 0, print_max = 200, repeat_count_threshold = 10, output_format = 0, format = 0, stop_print_at_null = 0, print_array_indexes = 0, deref_ref = 0, static_field_print = 1, pascal_static_field_print = 1, raw = 0, summary = 0, symbol_print = 1} (gdb) See the log above, it looks like the gdbpy_extract_lazy_string gives the wrong value "length = 2009291924", and the local_opts.print_max = 200. So in this case, do we need to compare those two values, and set length to local_opts.print_max? Yuanhui Zhang gdb/python/py-prettyprint.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gdb/python/py-prettyprint.c b/gdb/python/py-prettyprint.c index b50e757..e0dd92b 100644 --- a/gdb/python/py-prettyprint.c +++ b/gdb/python/py-prettyprint.c @@ -332,7 +332,9 @@ print_string_repr (PyObject *printer, const char *hint, gdbpy_extract_lazy_string (py_str, &addr, &type, &length, &encoding); - local_opts.addressprint = 0; + if (length > local_opts.print_max) + length = local_opts.print_max; + local_opts.addressprint = 0; val_print_string (type, encoding, addr, (int) length, stream, &local_opts); } ------------------------- The above patch fix the crash problem, but I'm not sure it was good or just a workaround. Yuanhui Zhang OK, I think the pushed fix in Bug #16196 (https://sourceware.org/bugzilla/show_bug.cgi?id=16196#c2) should also fix this bug. Look at the crash report in comment 2, I have such backtrace: #0 malloc_failure (size=2009291924) at ../../gdb/gdb/utils.c:1049 #1 0x00634f3a in xmalloc (size=2009291924) at ../../gdb/gdb/common/common-utils.c:53 #2 0x004e4bc7 in read_string (addr=2293384, len=2009291924, width=1, fetchlimit=200, byte_order=BFD_ENDIAN_LITTLE, buffer=0x298f584, bytes_read=0x298f588) at ../../gdb/gdb/valprint.c:1804 #3 0x004e66f8 in val_print_string (elttype=0x4bad438, encoding=0x0, addr=2293384, len=2009291924, stream=0x2ec2f68, options=0x298f5e4) at ../../gdb/gdb/valprint.c:2475 #4 0x0046ecfe in print_string_repr (printer=0x31075f8, hint=0x58a91e8 "string", stream=0x2ec2f68, recurse=1, options=0x298f9d4, language=0x7ee360 <cplus_language_defn>, gdbarch=0x2ebd520) at ../../gdb/gdb/python/py-prettyprint.c:336 The final reason is that xmalloc(size=2009291924) get a two large and random size value. My fix in comment 5 try to limit the size in function print_string_repr(), which is located as 4th frame in the backtrace above. The fix in Bug #16196 did a better job, because it limit the size in read_string() function, which is second frame in the backtrace, so it fixed in a lower level. Many other cases which call read_string() is fixed now. I just build the current gdb git HEAD, and did some test again, GDB.exe did not crash on showing un-initialized variables. So, I personally think this bug is fixed now, what do you guys think? Thanks. See the text for PR 16286 for more discussion of this issue. *** 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. (In reply to asmwarrior from comment #6) > I just build the current gdb git HEAD, and did some test again, GDB.exe did > not crash on showing un-initialized variables. > > So, I personally think this bug is fixed now, what do you guys think? I think so too, so can we close this? I think the crash issue I reported about 10 years ago is fixed already. I use GDB under Windows day by day, and I haven't seen GDB crashed on an initialized variable for a very long time. Fixed some time ago. |