This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


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

Re: insight crash


Barry Branham wrote:
> 
> Fernando Nasser wrote:
> 
> > Barry Branham wrote:
> > >
> > > I recompiled gnomine with -g.  Insight again just starts with a blank source
> > > window - no menu bar, just the frame.  'ddd' opens it fine, however.
> > >
> >
> > At the bottom of the source window there are two comboboxes.  Do they
> > show
> > any files in there?
> >
> 
> No, it's just a frame from the window manager.
> 

Something went wrong when instantiating the Source Window class...

You can see what went wrong by setting the following environment
variables:

setenv GDBTK_DEBUGFILE /dev/tty
setenv GDBTK_DEBUG 2

Take a look at the log and see if there is an obvious error message
(or post it so I can take a look).


> It occured to me it might help you if I got the to top of the stack trace I sent last
> time from running Insight with Dash so I made a tall window and held the return key.
> Here's the result:
> 
Now we are cooking.

It seems that you've hit a bug in the GDB C++ symbol overloading
routines.

I Will revert the order of the frames so I can comment:

> 
> #130919 0x813153c in gdb_search (clientData=0x8131344, interp=0x8358b58, objc=5,
>     objv=0x83597d4) at ./gdbtk/generic/gdbtk-cmds.c:1618

Here is where Insight calls GDB to get information about the symbol
"main".

> #130918 0x80982e9 in search_symbols (
> regexp=0x83ab470 "main",
> 
> kind=FUNCTIONS_NAMESPACE,
>     nfiles=0
> 
> , files=0x0, matches=0xbfffdab4) at symtab.c:2555

Here we are not in Insight anymore.  We are in GDB (file symtab.c) where
this function "search_symbols", looking for "main". We are looking for a
function
because  kind=FUNCTIONS_NAMESPACE.

Here is this function definition (from GDB sources).

/* Search the symbol table for matches to the regular expression REGEXP,
   returning the results in *MATCHES.

   Only symbols of KIND are searched:
   FUNCTIONS_NAMESPACE - search all functions
   TYPES_NAMESPACE     - search all type names
   METHODS_NAMESPACE   - search all methods NOT IMPLEMENTED
   VARIABLES_NAMESPACE - search all symbols, excluding functions, type
names,
   and constants (enums)

   free_search_symbols should be called when *MATCHES is no longer
needed.
 */
void
search_symbols (char *regexp, namespace_enum kind, int nfiles, char
*files[],
		struct symbol_search **matches)


> #130917 0x8096100 in lookup_symbol (name=0x85759a8
> "mainWindowWidget__C14VkSimpleWindow",
>     block=0x0, namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0x0) at
> symtab.c:595

We found a partial match (it is not a function though).

> #130916 0x8096100 in lookup_symbol (name=0x85759a8
> "mainWindowWidget__C14VkSimpleWindow",
>     block=0x863ac6c, namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0x0)
>     at symtab.c:595

Found the same symbol again.

> #130915 0x8096100 in lookup_symbol (name=0x85759a8
> "mainWindowWidget__C14VkSimpleWindow",
>     block=0x863ac6c, namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0x0)
>     at symtab.c:595

And again.


And this repeats until memory is exhausted.
 
(gdb) bt
#0  0x401cb245 in chunk_alloc (ar_ptr=0x0, nb=0) at malloc.c:2736
#1  0x401cb08e in __libc_malloc (bytes=32) at malloc.c:2704
#2  0x80d853a in xmmalloc (md=0x0, size=32) at utils.c:1024
#3  0x80d85a8 in xmalloc (size=32) at utils.c:1059
#4  0x8185274 in string_need (s=0xbf800290, n=16) at cplus-dem.c:4721
#5  0x81853c5 in string_appendn (p=0xbf800290,

It may be possible to repeat this crash without the GUI.  Maybe a 
"info function main" command in console mode (gdb -nw) will also
dump core.

If I could reproduce this here I could ask someone from the GDB symbols
area
to take a look at it.

Can you try to cause the core dump with a soer of Hello, world! program
that links to
this library and send me the binary?  I could foward this to someone I
believe will
be able to tell us something about this...



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

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