From mboxrd@z Thu Jan 1 00:00:00 1970 From: Barry Branham To: Fernando Nasser Cc: insight@sourceware.cygnus.com Subject: Re: insight crash Date: Sun, 07 Jan 2001 13:44:00 -0000 Message-id: <3A58E415.6C53B97C@networkusa.net> References: <3A57A8F3.F0B8FB49@networkusa.net> <3A57ACA5.C336387E@redhat.com> <3A57DEEB.C0CA5874@networkusa.net> <3A588848.C520230@redhat.com> <3A589F95.8F407222@networkusa.net> <3A58B007.581CB93F@redhat.com> X-SW-Source: 2001-q1/msg00024.html 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. > > Do you have any ~/.gdbinit file around? > > Another thing to try: delete your ~/.gdbtkinit file and see if it makes > any > difference. > Deleted ~/.gdbtkinit (no .gdbinit). Retried Insight with gnomine, same result. > > > Here's the result of running my application with Insight and then using regular > > gdb on the resulting Insight core with a longer backtrace - the looping stack > > frame involves 'VkSimpleWindow' which is part of the Viewkit package I > > mentioned. As noted in my first post, I was using Insight to debug this same > > program on RH 6.2 before I changed to RH7.0 and it worked. > > > > Now I am getting confused. This is supposed to be a core dum of gdb > right? > It runs in one address space while your program, that gdb calls the > "inferior" > runs in another address space. Gdb only sees your program's stack > because it > reads small chunks of inferior memory using system calls (ptrace). > > Bottom line: you can't see the inferior programs stack in a core dump > from a > gdb program. > > Maybe this core dump is from your application. The file command says it > is a 'gdb' > core file because your program was invoked through GDB (so the command > line where > it was started from was actually "gdb"). > > But this is just a theory. And it does not explain why it works with > -nw. My Dash app isn't crashing right now, the core is from Insight. > > > Can you try the following: > gdb -x -nw /usr/local/bin/Dash > ... > symbol-file /usr/local/bin/Dash > Tried running with '-x -nw': got the same segfault after it churned awhile. 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: -------------- #130913 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 #130914 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 #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 #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 #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 #130918 0x80982e9 in search_symbols ( regexp=0x83ab470 "main", kind=FUNCTIONS_NAMESPACE, nfiles=0 , files=0x0, matches=0xbfffdab4) at symtab.c:2555 #130919 0x813153c in gdb_search (clientData=0x8131344, interp=0x8358b58, objc=5, objv=0x83597d4) at ./gdbtk/generic/gdbtk-cmds.c:1618 #130920 0x8130750 in wrapped_call (opaque_args=0xbfffdbf0) at ./gdbtk/generic/gdbtk-cmds.c:573 #130921 0x80d5d96 in catch_errors (func=0x8130738 , args=0xbfffdbf0, errstring=0x82b1e60 "", mask=6) at top.c:485 #130922 0x8130671 in call_wrapper (clientData=0x8131344, interp=0x8358b58, objc=5, objv=0x83597d4) at ./gdbtk/generic/gdbtk-cmds.c:503 #130923 0x823f5dd in TclExecuteByteCode (interp=0x8358b58, codePtr=0x85222d8) at ./../generic/tclExecute.c:955 #130924 0x8227529 in Tcl_EvalObj (interp=0x8358b58, objPtr=0x8474c18) at ./../generic/tclBasic.c:2645 #130925 0x825ba71 in TclObjInterpProc (clientData=0x83cc060, interp=0x8358b58, objc=1, objv=0x83597d0) at ./../generic/tclProc.c:996 #130926 0x823f5dd in TclExecuteByteCode (interp=0x8358b58, codePtr=0x85295c8) at ./../generic/tclExecute.c:955 #130927 0x8227529 in Tcl_EvalObj (interp=0x8358b58, objPtr=0x845e3e0) at ./../generic/tclBasic.c:2645 #130928 0x8198718 in Itcl_EvalMemberCode (interp=0x8358b58, mfunc=0x84d4398, member=0x84d43b0, contextObj=0x0, objc=1, objv=0x83597cc) at /data/inst/insight+dejagnu-20010106/itcl/itcl/generic/itcl_methods.c:1029 #130929 0x819916f in Itcl_ExecProc (clientData=0x84d4398, interp=0x8358b58, objc=1, objv=0x83597cc) at /data/inst/insight+dejagnu-20010106/itcl/itcl/generic/itcl_methods.c:1605 #130930 0x823f5dd in TclExecuteByteCode (interp=0x8358b58, codePtr=0x85b4ff0) at ./../generic/tclExecute.c:955 #130931 0x8227529 in Tcl_EvalObj (interp=0x8358b58, objPtr=0x8474798) at ./../generic/tclBasic.c:2645 #130932 0x825ba71 in TclObjInterpProc (clientData=0x844bb30, interp=0x8358b58, objc=1, ---Type to continue, or q to quit--- objv=0x83597c8) at ./../generic/tclProc.c:996 #130933 0x823f5dd in TclExecuteByteCode (interp=0x8358b58, codePtr=0x85adf38) at ./../generic/tclExecute.c:955 #130934 0x8227529 in Tcl_EvalObj (interp=0x8358b58, objPtr=0x84379d0) at ./../generic/tclBasic.c:2645 #130935 0x822730e in Tcl_Eval (interp=0x8358b58, string=0x82b2b92 "gdbtk_tcl_preloop") at ./../generic/tclBasic.c:2453 #130936 0x81356f8 in tk_command_loop () at ./gdbtk/generic/gdbtk-hooks.c:367 #130937 0x8082566 in captured_command_loop (data=0x0) at main.c:104 #130938 0x80d5d96 in catch_errors (func=0x808254c , args=0x0, errstring=0x8268733 "", mask=6) at top.c:485 #130939 0x8082f5f in captured_main (data=0xbffff8f0) at main.c:749 #130940 0x80d5d96 in catch_errors (func=0x8082594 , args=0xbffff8f0, errstring=0x8268733 "", mask=6) at top.c:485 #130941 0x8082f8b in main (argc=2, argv=0xbffff964) at main.c:761 #130942 0x4016dbfc in __libc_start_main (main=0x8082f64
, argc=2, ubp_av=0xbffff964, init=0x8080d4c <_init>, fini=0x82685cc <_fini>, rtld_fini=0x4000d674 <_dl_fini>, stack_end=0xbffff95c) at ../sysdeps/generic/libc-start.c:118 (gdb) (gdb) (gdb) (gdb) (gdb) Thanks Barry