Help with dbimp crash?

Help with dbimp crash?

[Joseph Pallas]

I've been encountering a crash in dbimp that seems to be due to a dangling
pointer, but I'm having trouble understanding how this stuff is supposed
to work.

I've narrowed the problem down to an entry in a hash table whose key is a
pointer that isn't valid.  At first I thought the pointer was getting
stomped on, but I started tracing things more thoroughly and discovered
that the entry didn't change, and the pointer was valid at the time the
entry was added. The memory that it pointed to, however, actually went
away sometime later.

The troublesome insertion occurs when the stack looks like this:

HashTableSearchFunc
HashTableAdd
f_MacroFind
f_TokenMacroInput

The value of item.key in HashTableAdd is a char pointer that was set to
sString.text in f_MacroFind.  This ultimately seems to be a pointer
derived from yytext in f_TokenInput.  Since yytext belongs to (f)lex,
expecting it to be stable and long-lived would be a mistake.

Could someone who actually understands this stuff tell me if I've got it
right?  If so, is it fixable?  I'm fairly petrified of trying a fix
without being sure of the problem and understanding how things are
supposed to work.  I really don't want to introduce a memory leak.

Thanks.
joe

Re: Help with dbimp crash?

[Syd Polk]

I am afraid the original developers who worked on that portion of 
Source-Navigator are long gone. This is not an area where we have much 
expertise anymore.

At 03:58 PM 8/28/00 -0700, Joseph Pallas wrote:
>I've been encountering a crash in dbimp that seems to be due to a dangling
>pointer, but I'm having trouble understanding how this stuff is supposed
>to work.
>
>I've narrowed the problem down to an entry in a hash table whose key is a
>pointer that isn't valid.  At first I thought the pointer was getting
>stomped on, but I started tracing things more thoroughly and discovered
>that the entry didn't change, and the pointer was valid at the time the
>entry was added. The memory that it pointed to, however, actually went
>away sometime later.
>
>The troublesome insertion occurs when the stack looks like this:
>
>HashTableSearchFunc
>HashTableAdd
>f_MacroFind
>f_TokenMacroInput
>
>The value of item.key in HashTableAdd is a char pointer that was set to
>sString.text in f_MacroFind.  This ultimately seems to be a pointer
>derived from yytext in f_TokenInput.  Since yytext belongs to (f)lex,
>expecting it to be stable and long-lived would be a mistake.
>
>Could someone who actually understands this stuff tell me if I've got it
>right?  If so, is it fixable?  I'm fairly petrified of trying a fix
>without being sure of the problem and understanding how things are
>supposed to work.  I really don't want to introduce a memory leak.
>
>Thanks.
>joe
>

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: Help with dbimp crash?

[Ben Elliston]

   I am afraid the original developers who worked on that portion of
   Source-Navigator are long gone. This is not an area where we have much
   expertise anymore.

I'm game to take a look.

Ben

Re: Help with dbimp crash?

[Ben Elliston]

   I've been encountering a crash in dbimp that seems to be due to a
   dangling pointer, but I'm having trouble understanding how this stuff
   is supposed to work.

The parsers pipe their output into dbimp.
Do you have an example of input that causes this problem?

Ben

Re: Help with dbimp crash?

[Joe Pallas]

At 10:10 AM +1100 8/29/00, Ben Elliston wrote:
>The parsers pipe their output into dbimp.
>Do you have an example of input that causes this problem?

I do, but it's not that simple.  When I feed the saved trace back 
into dbimp, it insists on reopening the source files and gets unhappy 
if they're not there.  I'm sure this has something to do with the 
mysterious fact that the c++ parser is linked into dbimp.  This makes 
it hard for me to provide a simple test case (the source files are 
proprietary).

joe