http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49084
--- Comment #11 from Cesar Strauss <cestrauss at gmail dot com> 2011-11-27 20:55:15 UTC --- Created attachment 25922 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25922 Debug log of PR49084 The cause of the access violation is due to an attempt to pass a null string pointer to asprintf in internal_error_function (gcc/ada/gcc-interface/misc.c:290): (gdb) frame 2 #2 0x0042bfad in internal_error_function (context=0x1a15800, msgid=0x11e08df "in %s, at %s:%d", ap=0x722faa4) at ../../../../gcc-svn-fixada/gcc/ada/gcc-interface/misc.c:290 290 asprintf (&loc, "%s:%d", s.file, s.line); (gdb) l 286 s = expand_location (input_location); 287 if (context->show_column && s.column != 0) 288 asprintf (&loc, "%s:%d:%d", s.file, s.line, s.column); 289 else 290 asprintf (&loc, "%s:%d", s.file, s.line); 291 temp_loc.Low_Bound = 1; 292 temp_loc.High_Bound = strlen (loc); 293 fp_loc.Bounds = &temp_loc; 294 fp_loc.Array = loc; (gdb) p input_location $1 = 0 (gdb) p s $2 = {file = 0x0, line = 0, column = 0, sysp = <optimized out>} It remains to be seen why input_location is zero. Maybe it's too early in the process execution? Earlier in the stack trace, there is an assertion triggered in gigi (ada/gcc-interface/trans.c:300): (gdb) fr 6 #6 0x00491875 in gigi (gnat_root=1707, max_gnat_node=2431, number_name=1656, nodes_ptr=0x7950020, next_node_ptr=0x78b52f8, prev_node_ptr=0x78e6050, elists_ptr=0x7708e78, elmts_ptr=0x77094d0, strings_ptr=0x7734818, string_chars_ptr=0x77320f0, list_headers_ptr=0x78a9760, number_file=3, file_info_ptr=0x722fb9c, standard_boolean=12, standard_integer=27, standard_character=72, standard_long_long_float=67, standard_exception_type=1281, gigi_operating_mode=0) at ../../../../gcc-svn-fixada/gcc/ada/gcc-interface/trans.c:300 300 gcc_assert (Nkind (gnat_root) == N_Compilation_Unit); (gdb) l 295 String_Chars_Ptr = string_chars_ptr; 296 List_Headers_Ptr = list_headers_ptr; 297 298 type_annotate_only = (gigi_operating_mode == 1); 299 300 gcc_assert (Nkind (gnat_root) == N_Compilation_Unit); 301 302 /* Declare the name of the compilation unit as the first global 303 name in order to make the middle-end fully deterministic. */ 304 t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL); (gdb) p gnat_root $3 = 1707 (gdb) p (Nodes_Ptr[(gnat_root) - 0].U.K.kind) $4 = 17 '\021' It seems Nkind (gnat_root) is N_Op_Add (17) for some reason. BTW this is trunk (svn 181738), with the stage 2 compiler (this bug is not manifest in the stage 1 compiler). Full debug log is attached.
