c++/2123: Segmentation Fault when using 'print' on data.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

c++/2123: Segmentation Fault when using 'print' on data.

Richard Corden

>Number:         2123
>Category:       c++
>Synopsis:       Segmentation Fault when using 'print' on data.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed May 10 16:38:01 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Richard Corden
>Release:        GDB-6.4
>Organization:
>Environment:
Linux 2.6.15.7 i686
>Description:
Basically, when debugging our (quite large) program sometimes when I examine code the debuger ends with a segmentation fault.

I have tried (and failed) to reproduce it in a simple example, but I did build a debug version of gdb and made enouch fixes to stop the problem.  The changes I made were:

--- ../gdb-6.4-orig/gdb/cp-valprint.c   2005-05-09 23:20:30.000000000 +0200
+++ gdb/cp-valprint.c   2006-05-10 15:22:59.000000000 +0200
@@ -271,6 +271,11 @@

  CHECK_TYPEDEF (type);

+  if (! TYPE_CPLUS_SPECIFIC (type))
+  {
+    return;
+  }
+
  fprintf_filtered (stream, "{");
  len = TYPE_NFIELDS (type);
  n_baseclasses = TYPE_N_BASECLASSES (type);


--- ../gdb-6.4-orig/gdb/gdbtypes.c      2005-06-27 10:38:13.000000000 +0200
+++ gdb/gdbtypes.c      2006-05-10 15:20:24.000000000 +0200
@@ -1269,7 +1269,7 @@
{
  CHECK_TYPEDEF (type);

-  if (TYPE_VPTR_FIELDNO (type) < 0)
+  if (TYPE_VPTR_FIELDNO (type) < 0 && TYPE_CPLUS_SPECIFIC (type))
    {
      int i;


--- ../gdb-6.4-orig/gdb/valops.c        2005-05-27 06:39:32.000000000 +0200
+++ gdb/valops.c        2006-05-10 15:17:00.000000000 +0200
@@ -1155,6 +1155,12 @@
                    struct type *type, int looking_for_baseclass)
{
  int i;
+
+  if (! TYPE_CPLUS_SPECIFIC(type))
+  {
+    return NULL;
+  }
+   int nbases = TYPE_N_BASECLASSES (type);

  CHECK_TYPEDEF (type);



For the last change here was some of the backtrace:

#0  0x080e3ec2 in search_struct_method (name=0xbbb5ab0 "U_Ref", arg1p=0xc1e1ff0, args=0x0, offset=203311936, static_memfuncp=0x1, type=0xc1e1e4c) at valops.c:1509
#1  0x080e401e in search_struct_method (name=0xbbb5ab0 "U_Ref", arg1p=0xc1e1ff0, args=0x0, offset=203300428, static_memfuncp=0x1, type=0xc1e1e4c) at valops.c:1436
#2  0x080e282b in value_assign (toval=0xc1e1e4c, fromval=0xbb8c770) at valops.c:603
#3  0x080e171a in evaluate_subexp_for_address (exp=0x37, pos=0xc1e1ff0, noside=3221217828) at eval.c:2173
#4  0x080ddf7e in evaluate_subexp_standard (expect_type=0x0, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:1775
#5  0x080e1ddd in value_cast (type=0x0, arg2=0x3) at valops.c:299
#6  0x080ddf7e in evaluate_subexp_standard (expect_type=0x0, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:1775
#7  0x080e1ddd in value_cast (type=0x0, arg2=0x82efcd0) at valops.c:299
#8  0x080ddf7e in evaluate_subexp_standard (expect_type=0x0, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:1775
#9  0x080e1ddd in value_cast (type=0x0, arg2=0xbb822d0) at valops.c:299
#10 0x080ddf7e in evaluate_subexp_standard (expect_type=0x0, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:1775
#11 0x080e0363 in evaluate_subexp_standard (expect_type=0x1, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:493
#12 0x080ddf7e in evaluate_subexp_standard (expect_type=0xbb20000, exp=0xb769710, pos=0xbfffe224, noside=EVAL_NORMAL) at eval.c:1775
#13 0x080de14e in evaluate_subexp_standard (expect_type=0xbfffe1e0, exp=0xbfffe25c, pos=0x0, noside=137145904) at eval.c:1816
#14 0x080ebef0 in address_info (exp=0xbfffe310 "\227\226²\v", from_tty=0) at ../gdb/printcmd.c:1088
#15 0x080ebf53 in address_info (exp=0xbb2964e "(((U_LocationData*)((loc).m_locData.m_b)).m_filename.m_abs.m_key)->c_str()", from_tty=0) at ../gdb/printcmd.c:1096
#16 0x080b13f4 in define_command (comname=0x82b41b0 "øì+\beÙ&\b\001", from_tty=196253262) at ../gdb/cli/cli-script.c:1150
#17 0x080b3184 in init_cli_cmds () at ../gdb/cli/cli-cmds.c:1115
#18 0x080839bc in xvasprintf (ret=0xc1e4b40, format=0x0, ap=0xbbc2e20 "") at utils.c:1063
#19 0x080b3684 in init_cli_cmds () at ../gdb/cli/cli-cmds.c:1227
#20 0x080b35a9 in init_cli_cmds () at ../gdb/cli/cli-cmds.c:1209
#21 0x080839da in xstrvprintf (format=0x82a0d3d "c", ap=0x1 <Address 0x1 out of bounds>) at utils.c:1070
#22 0x0810c3c3 in get_character_constant (tok=0x82a0d38, p=0x82aca40 "pl loc", end=0x8085dba "ì\bVSè\215þÿÿ\203Ä\020\205ÿuÖ\203À\002ëÑPQVSè¸þÿÿëé\215¶") at macroexp.c:331
#23 0x0810c847 in append_tokens_without_splicing (dest=0x82a0d38, src=0x82cc790) at macroexp.c:618
#24 0x081e2389 in bfd_elf_final_link (abfd=0xc, info=0x0) at elflink.c:8088
#25 0x0810bd1b in _initialize_macrocmd () at macrocmd.c:234
#26 0x0810c2ba in get_pp_number (tok=0x0, p=0x0, end=0xbb745f0 " Ù\213\b") at macroexp.c:284
#27 0x0810b55a in interpreter_exec_cmd (args=0x0, from_tty=-1208573964) at interps.c:389
#28 0x0810b027 in interp_set (interp=0x0) at interps.c:134
#29 0x0810b098 in interp_set (interp=0x0) at interps.c:174
#30 0x0808362f in internal_warning (file=0x82d1ca0 "\002", line=-1073748496, string=0xbfffe5b8 "øåÿ¿x6\b\b 6\b\b \034-\bðåÿ¿èåÿ¿ìåÿ¿ÛP \b") at utils.c:839
#31 0x080834fe in internal_vproblem (problem=0xbfffe500, file=0x82d1ca0 "\002", line=-1073748496, fmt=0xbfffe5e8 "\001", ap=0xbfffe5ec "") at utils.c:786
#32 0x08083678 in perror_with_name (string=0x810b060 "+\b\205Û\2115pv*\bt\027\203ì\bS\213\006Pè8\004÷ÿ\203Ä\020\205À\017\205\r\001") at utils.c:866
#33 0x080bef33 in tui_field_string (uiout=0xb7f6da20, fldno=-1073748416, width=-1209321964, align=6, fldname=0x82050db "\203þ\t\177\020\213EÄ\205Àt\031\211ö\215¼'", string=0x0) at ../gdb/tui/tui-out.c:282
#34 0x08109034 in func_command (arg=0x0, from_tty=-1073748304) at stack.c:1896
#35 0x0807affb in ?? ()
#36 0x00000000 in ?? ()
#37 0xbfffe6b0 in ?? ()
#38 0xbfffe678 in ?? ()


The difference in the output of the debugger is that when I examine my data some of the fields are blank, eg:

{<> = {_vptr.Ref = 0x8048890}, m_i = 10}

vs

{<Ref> = {_vptr.Ref = 0x8048890}, m_i = 10}



I hope this is enough information for you.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: