public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
* Has anyone run into this crash before?
@ 2000-10-25 17:45 Mo DeJong
  2000-10-26  1:13 ` Fernando Nasser
  2000-10-26 14:05 ` Eray Ozkural
  0 siblings, 2 replies; 4+ messages in thread
From: Mo DeJong @ 2000-10-25 17:45 UTC (permalink / raw)
  To: insight

I have been seeing lots of core dumps in insight when
expanding a variable in the watch window (by clicking
on the little + symbol). When I look at it in
gdb, I get a stack trace like this:

#0  Tcl_NewListObj (objc=2, objv=0x833ff30) at 
../../../insight/src/tcl/unix/../generic/tclListObj.c:100
#1  0x8219ebb in InfoLevelCmd (dummy=0x0, interp=0x833f1c0, objc=3, 
objv=0x8d39f9c) at ../../../insight/src/tcl/unix/../generic/tclCmdIL.c:1087
#2  0x82195fc in Tcl_InfoObjCmd (clientData=0x0, interp=0x833f1c0, 
objc=3, objv=0x8d39f9c) at 
../../../insight/src/tcl/unix/../generic/tclCmdIL.c:401
#3  0x822bf60 in TclExecuteByteCode (interp=0x833f1c0, codePtr=0x84bf1f8) 
at ../../../insight/src/tcl/unix/../generic/tclExecute.c:955
#4  0x821448d in Tcl_EvalObj (interp=0x833f1c0, objPtr=0x845ccd8) at 
../../../insight/src/tcl/unix/../generic/tclBasic.c:2645
#5  0x82476f1 in TclObjInterpProc (clientData=0x845ba60, 
interp=0x833f1c0, objc=2, objv=0x8d39f90) at 
../../../insight/src/tcl/unix/../generic/tclProc.c:996
#6  0x8240131 in InvokeImportedCmd (clientData=0x8432720, 
interp=0x833f1c0, objc=2, objv=0x8d39f90) at 
../../../insight/src/tcl/unix/../generic/tclNamesp.c:1452
#7  0x822bf60 in TclExecuteByteCode (interp=0x833f1c0, codePtr=0x8a284c0) 
at ../../../insight/src/tcl/unix/../generic/tclExecute.c:955
#8  0x821448d in Tcl_EvalObj (interp=0x833f1c0, objPtr=0x8a6e280) at 
../../../insight/src/tcl/unix/../generic/tclBasic.c:2645
#9  0x818a559 in Itcl_EvalMemberCode (interp=0x833f1c0, mfunc=0x8a39d40, 
member=0x8a39d58, contextObj=0x8a37ec8, objc=2, objv=0x833ff30) at 
/mnt/image/insight/src/itcl/itcl/generic/itcl_methods.c:1029
#10 0x818ad2d in Itcl_ExecMethod (clientData=0x8a39d40, interp=0x833f1c0, 
objc=2, objv=0x833ff30) at 
/mnt/image/insight/src/itcl/itcl/generic/itcl_methods.c:1546
#11 0x822bf60 in TclExecuteByteCode (interp=0x833f1c0, codePtr=0x8a91658) 
at ../../../insight/src/tcl/unix/../generic/tclExecute.c:955
#12 0x821448d in Tcl_EvalObj (interp=0x833f1c0, objPtr=0x8a6e208) at 
../../../insight/src/tcl/unix/../generic/tclBasic.c:2645
#13 0x818a559 in Itcl_EvalMemberCode (interp=0x833f1c0, mfunc=0x8a32418, 
member=0x8a32430, contextObj=0x8a37ec8, objc=2, objv=0x833ff28) at 
/mnt/image/insight/src/itcl/itcl/generic/itcl_methods.c:1029
#14 0x818ad2d in Itcl_ExecMethod (clientData=0x8a32418, interp=0x833f1c0, 
objc=2, objv=0x833ff28) at 
/mnt/image/insight/src/itcl/itcl/generic/itcl_methods.c:1546
#15 0x819044f in Itcl_EvalArgs (interp=0x833f1c0, objc=2, objv=0x833ff28) 
at /mnt/image/insight/src/itcl/itcl/generic/itcl_util.c:1337
#16 0x818c3fc in Itcl_HandleInstance (clientData=0x8a37ec8, 
interp=0x833f1c0, objc=3, objv=0x833ff24) at 
/mnt/image/insight/src/itcl/itcl/generic/itcl_objects.c:664
#17 0x822bf60 in TclExecuteByteCode (interp=0x833f1c0, codePtr=0x8a90aa8) 
at ../../../insight/src/tcl/unix/../generic/tclExecute.c:955
#18 0x821448d in Tcl_EvalObj (interp=0x833f1c0, objPtr=0x8a42128) at 
../../../insight/src/tcl/unix/../generic/tclBasic.c:2645

There are about 90 frames on this stack, so I just posted the first couple.

It gets a SIGSEGV in Tcl_NewListObj(objc, objv).

    elemPtrs = (Tcl_Obj **)
        ckalloc((unsigned) (objc * sizeof(Tcl_Obj *)))
    for (i = 0;  i < objc;  i++) {
	elemPtrs[i] = objv[i];
        Tcl_IncrRefCount(elemPtrs[i]);   <--- Boom!
    }

(gdb) print i
$16 = 0

(gdb) print elemPtrs[0]
$18 = (Tcl_Obj *) 0x3230322e

(gdb) print *(elemPtrs[0])
Error: Cannot access memory at address 0x3230322e


The Tcl call stack looks like:

VariableWin::open
    VariableWin::populate

In this function, the following imported method is called:

debug "inserting variable: $variable"

That ends up calling dbug in debug.tcl, it crashes in
the first call to [info level].

  proc dbug {level msg} {
    set cls [string trimleft [uplevel namespace current] :]
    if {$cls == ""} {
      set cls "global"
    }
    
    set i [expr {[info level] - 1}]
    if {$i > 0} {
      set func [lindex [info level $i] 0]
    } else {
      set func ""
    }
    
    ::debug::_putdebug $level $cls $func $msg
  }

invoke:

Tcl_NewListObj(framePtr->objc, framePtr->objv);

So it would seem that the framePtr->objv
is getting set a some bad memory.

The bad mem seems to come from this loop (in tclCmdIL.c).

1077	        for (framePtr = iPtr->varFramePtr;  framePtr != NULL;
1078	                framePtr = framePtr->callerVarPtr) {
1079	            if (framePtr->level == level) {
1080	                break;
1081	            }
1082	        }


So it seems Tcl is trying to walk back over its
caller stack and find the frame from 2 stacks ago.
It blows up doing that.

Any ideas where this could be getting triggered
and how to fix it?

Mo DeJong
Red Hat Inc

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Has anyone run into this crash before?
  2000-10-25 17:45 Has anyone run into this crash before? Mo DeJong
@ 2000-10-26  1:13 ` Fernando Nasser
  2000-10-26 14:05 ` Eray Ozkural
  1 sibling, 0 replies; 4+ messages in thread
From: Fernando Nasser @ 2000-10-26  1:13 UTC (permalink / raw)
  To: Mo DeJong; +Cc: insight

Mo DeJong wrote:
> 
> I have been seeing lots of core dumps in insight when
> expanding a variable in the watch window (by clicking
> on the little + symbol). When I look at it in
> gdb, I get a stack trace like this:
> 
> #0  Tcl_NewListObj (objc=2, objv=0x833ff30) at
> ../../../insight/src/tcl/unix/../generic/tclListObj.c:100
> #1  0x8219ebb in InfoLevelCmd (dummy=0x0, interp=0x833f1c0, objc=3,
> objv=0x8d39f9c) at ../../../insight/src/tcl/unix/../generic/tclCmdIL.c:1087
> #2  0x82195fc in Tcl_InfoObjCmd (clientData=0x0, interp=0x833f1c0,
> objc=3, objv=0x8d39f9c) at
> ../../../insight/src/tcl/unix/../generic/tclCmdIL.c:401

Yes, but that was fixed a while ago.
You should not see this with the latest sources.

If you are seeing this with the latest source please send me the
"how to reproduce" instructions (even better, fill in a problem report
in the web page).

Thanks.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Has anyone run into this crash before?
  2000-10-26 14:05 ` Eray Ozkural
@ 2000-10-26 14:00   ` Mo DeJong
  0 siblings, 0 replies; 4+ messages in thread
From: Mo DeJong @ 2000-10-26 14:00 UTC (permalink / raw)
  To: insight

On Thu, 26 Oct 2000, Eray Ozkural wrote:

> Mo DeJong wrote:
> > 
> > I have been seeing lots of core dumps in insight when
> > expanding a variable in the watch window (by clicking
> > on the little + symbol). When I look at it in
> > gdb, I get a stack trace like this:
> 
> My watch window freezes when I try ot expand some C++
> variables like instances of complex classes (with inheritance
> and templates)
> 
> I can provide a test case if you'd like.

A really small test case would be great. My problem
is that I run into this bug in some really wacky
and complex situation after my own app has
crashed. Then Insight crashes, and I am extra
miffed because I just lost the real crash in
my application (no core file).

I was using the most recent code from the CVS,
and I can't reproduce the crash.

Mo DeJong
Red Hat Inc

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Has anyone run into this crash before?
  2000-10-25 17:45 Has anyone run into this crash before? Mo DeJong
  2000-10-26  1:13 ` Fernando Nasser
@ 2000-10-26 14:05 ` Eray Ozkural
  2000-10-26 14:00   ` Mo DeJong
  1 sibling, 1 reply; 4+ messages in thread
From: Eray Ozkural @ 2000-10-26 14:05 UTC (permalink / raw)
  To: Mo DeJong; +Cc: insight

Mo DeJong wrote:
> 
> I have been seeing lots of core dumps in insight when
> expanding a variable in the watch window (by clicking
> on the little + symbol). When I look at it in
> gdb, I get a stack trace like this:

My watch window freezes when I try ot expand some C++
variables like instances of complex classes (with inheritance
and templates)

I can provide a test case if you'd like.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-10-26 14:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-25 17:45 Has anyone run into this crash before? Mo DeJong
2000-10-26  1:13 ` Fernando Nasser
2000-10-26 14:05 ` Eray Ozkural
2000-10-26 14:00   ` Mo DeJong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).