fintanr's weblog

Archives
« February 2005 »
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
      
       
Today

the links















blogs.sun.com
Weblog
Login



All | Books | Gadgets | General | JES | OpenSolaris | Perl | Services | Slamd | Solaris | Travels | Tunes

« Previous day (Feb 14, 2005) | Main | Next day (Feb 15, 2005) »
20050215 Tuesday February 15, 2005

mdb core....
I ran into an interesting problem today, which unfortunately time (and a crash) didn't permit me to debug fully, but I'll share the mdb section of it with you anyway. I went to start up gvim on my desktop and it decided (well more accurately gnome decided) that it was having none of this, so a quick interrupt later I had a core dump. Anyway, I don't have dbx on my laptop at the moment, so time to fire up mdb... 

> ::status
debugging core file of vim (32-bit) from dhcp-syd04-12-6
file: /export/home/fintanr/bin/vim
initial argv: gvim
threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
So this isn't really telling me more than I killed off the process myself, now lets take a look at whats happening. 
> ::walk thread | ::findstack
stack pointer for thread 1: 81c3098
[ 081c3098 libc.so.1`kill+0x15() ]
  081c30a8 mch_exit+0x92()
  081c30c8 getout+0x19c()
  081c30e8 preserve_exit+0xaa()
  081c30f8 0x811fc59()
  081c310c libc.so.1`__sighndlr+0xf()
  081c3164 libc.so.1`call_user_handler+0x22b()
  081c3188 libc.so.1`sigacthandler+0xbb()
  08046aa8 libICE.so.6`_IceRead+0x92()
  08046ae0 libICE.so.6`IceProcessMessages+0x42()
  08046c64 libICE.so.6`IceOpenConnection+0x2a4()
  08046ce8 libSM.so.6`SmcOpenConnection+0xd6()
  08046e38 xsmp_init+0xd4()
  08046f58 main+0x15b0()
  08046f80 _start+0x5d()
Hmmm, now a quick look around on google shows us that a similar type error occurs when gnome can't resolve a name after a network connection has been interrupted on Fedora core (see the bugzilla entry, so I start up gvim again and then used gcore(1M) to grab a core of my gnome-session, and takek a look at whats happening.... 

Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> ::status
debugging core file of gnome-session (32-bit) from dhcp-syd04-12-6
file: /usr/bin/gnome-session
initial argv: /usr/bin/gnome-session
threading model: multi-threaded
status: process core file generated with gcore(1)
> ::walk thread | ::findstack
stack pointer for thread 1: 8046ebc
[ 08046ebc libc.so.1`_waitid+0x15() ]
  08046ed8 libc.so.1`waitpid+0x75()
  08046f5c libgnomeui-2.so.0.600.1`libgnomeui_segv_handle+0xaf()
  08046fb4 libc.so.1`call_user_handler+0x22b()
  08046fd8 libc.so.1`sigacthandler+0xbb()
  08047200 libICE.so.6`_IceWrite+0x84()
  0804721c libICE.so.6`IceFlush+0x24()
  08047244 libICE.so.6`IceAcceptConnection+0x168()
  0810c368 accept_connection+0x25()
  08127410 libglib-2.0.so.0.400.1`g_source_callback_funcs()
  00000002 accept_connection()
>
And low and behold, yep, its a pretty similar bug. Unfortunately at this stage my gnome-session decided it had enough and died, but its a semi interesting one to look at. One to recreate when time is available and take a closer look with DTrace.
(2005-02-15 00:37:37.0) Permalink Comments [0]