This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83949

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As the preprocessed source comes from some early 5.x version (not even current
one, and 5.x is not maintained anymore anyway), can't check current trunk.
What I see in 5.x is that:
#3  0x0000000001132085 in ggc_internal_cleared_alloc (s=18446744072616236162)
at ../../gcc/ggc.h:149
#4  0x00000000011321ac in ggc_alloc_string (
    contents=0x7ff8a5f06020
"joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost"...,
length=-1093315455) at ../../gcc/stringpool.c:108
#5  0x000000000085d25a in pp_ggc_formatted_text (pp=0x32b2540
<scratch_pretty_printer>) at ../../gcc/cp/error.c:2761
#6  0x0000000000859f36 in decl_as_string (decl=<type_decl 0x7fffd8bcbbe0
joint_iter>, flags=6148) at ../../gcc/cp/error.c:2814
#7  0x0000000000859ece in decl_as_dwarf_string (decl=<type_decl 0x7fffd8bcbbe0
joint_iter>, flags=6148) at ../../gcc/cp/error.c:2802
#8  0x000000000070ca78 in cxx_dwarf_name (t=<type_decl 0x7fffd8bcbbe0
joint_iter>, verbosity=2) at ../../gcc/cp/cp-lang.c:135
#9  0x0000000000bb1a47 in type_tag (type=0x7fffd8bce888) at
../../gcc/dwarf2out.c:17449
#10 0x0000000000bbc7dc in gen_struct_or_union_type_die (type=<record_type
0x7fffd8bce888 joint_iter>, 
    context_die=<dw_die_ref 0x7fffefa5c0a0 DW_TAG_namespace
<parent=0x7fffefa5c050 DW_TAG_namespace>>, usage=DINFO_USAGE_DIR_USE)
    at ../../gcc/dwarf2out.c:20014

where decl_as_string for some instantiation needs almost 3GB long string and
ggc_strdup only supports strings < 2GB, as ggc_alloc_string has int length
argument and tree_string has int length field.
Supporting >= 2GB and < 4GB or even >= 4GB STRING_CSTs would be hard, making
ggc_strdup work for >= 2GB coudl mean just:
--- gcc/stringpool.c.jj 2018-01-03 10:19:55.544534019 +0100
+++ gcc/stringpool.c    2018-01-20 14:28:54.452768825 +0100
@@ -70,15 +70,16 @@ alloc_node (cpp_hash_table *table ATTRIB
 const char *
 ggc_alloc_string (const char *contents, int length MEM_STAT_DECL)
 {
+  size_t len = length;
   if (length == -1)
-    length = strlen (contents);
+    len = strlen (contents);

-  if (!length)
+  if (!len)
     return "";

-  char *result = (char *) ggc_alloc_atomic (length + 1);
-  memcpy (result, contents, length);
-  result[length] = '\0';
+  char *result = (char *) ggc_alloc_atomic (len + 1);
+  memcpy (result, contents, len);
+  result[len] = '\0';

   return (const char *) result;
 }

But, even if it doesn't crash with this, I doubt it would actually produce any
useful debug info, except for MIPS we emit 32-bit DWARF and so .debug_str
offsets need to fit into 4GB for the whole shared library or binary.  If you
have 3GB long just a single string, I doubt you can fit the rest into 1GB. 
Perhaps don't abuse templates that much?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]