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 middle-end/17044] [3.5 Regression] libgcc2.c:169: internal compiler error: Segmentation fault


------- Additional Comments From law at redhat dot com  2004-08-24 20:04 -------
Subject: Re:  [3.5 Regression] libgcc2.c:169:
	internal compiler error: Segmentation fault

On Tue, 2004-08-24 at 14:00, dave at hiauly1 dot hia dot nrc dot ca
wrote:
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-08-24 20:00 -------
> Subject: Re:  [3.5 Regression] libgcc2.c:169: internal c
> 
> > > The exception occurs in the following call to free:
> > > 
> > > Breakpoint 13, 0x400000000031e350 in thread_block (bb=0x800003fffeacd8c0)
> > >     at ../../gcc/gcc/tree-ssa-threadupdate.c:381
> > > 381           free (rd);
> > > (gdb) bt
> > > #0  0x400000000031e350 in thread_block (bb=0x800003fffeacd8c0)
> > >     at ../../gcc/gcc/tree-ssa-threadupdate.c:381
> > OK.  That means there's got to be a memory management error of some
> > kind.  I wonder if we're freeing GC'd memory or something stupid like
> > that.
> 
> That might be the case although I didn't actually determine how the
> object was created.  I know the fault occurred for i = 0 and all = false.
> 
> One problem is that the varray is a local and it's created and
> managed using VARRAY macros that use GC.  There's also a missing
> "struct" in the call to xcalloc.
> 
> I have an alternate fix that uses NOGC macros and VARRAY_FREE if
> it's preferable to use malloc for the allocation of the varray.
Let's go with your original fix -- I really dislike the NOGC stuff.

jeff
> 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17044


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