This is the mail archive of the gcc@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]

RE: Segmentation Fault (core dump)


On 07 March 2006 15:38, Neeta Kale wrote:

> I am running a program which is compiled using GCC
> 2.95.3. When I run the program, I get the following
> error :
> Segmentation Fault (core dumped)

  Your program is almost certainly buggy.  Please send general how-to-program
questions to the gcc-help list.  This list is about how to write and modify
the internal program code of the compiler itself, not about how to write
programs *with* the compiler.  You should only report it here if it was the
compiler that segfaulted, or if you have some reason to beleive the compiler
mistranslated your source files and generated incorrect code that caused the
segfault.

> (gdb) run
> Starting program: /home/proj/Test
> Program received signal SIGSEGV, Segmentation fault.
> 0x00119c80 in _Rb_tree<char const *, pair<char const
> *const, void *>, _Select1st<pair<char const *const,
> void *> >, less<char const *>, allocator<void *>
>>>> lower_bound at
> /usr/local/include/g++-3/stl_tree.h:1169
> 1169 _Link_type __x = _M_root(); /* Current node. */
> (gdb) where
> #0 0x00119c80 in _Rb_tree<char const *, pair<char
> const *const, void *>, _Select1st<pair<char const
> *const, void *> >, less<char const *>, allocator<void
> *> >::lower_bound at
> /usr/local/include/g++-3/stl_tree.h:1169
> #1 0x00173b2c in map<char const *, void *, less<char
> const *>, allocator<void *> >::lower_bound at
> /usr/local/include/g++-3/stl_map.h:190
> #2 0x00171bc8 in map<char const *, void *, less<char
> const *>, allocator<void *> >::operator[] at
> /usr/local/include/g++-3/stl_map.h:151
> (gdb)
> 
> Is it possible that some library might be missing or
> do I need to use some compile options in order to get
> rid of this error.

  Nope, it most likely means you have a bug to fix.  Just because the crash
occurs in a library function doesn't mean the library is at fault; 99 times
out of 100 it means you passed invalid values to library functions, or
overwrote vital heap or stack memory where the library function had some
storage.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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