From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <25c6a88bbd3ebfd4f4e20315d4ad1a54@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Forwarded attachment... In-Reply-To: <2919a26ef6f18d0b1c9dc29e082a60e0@plan9.ucalgary.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-favcvtvvmnigkcwskhmfvrcrut" Date: Fri, 19 Dec 2003 17:40:06 -0500 Topicbox-Message-UUID: acd6ef44-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-favcvtvvmnigkcwskhmfvrcrut Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The problem was links trying to (successfully) kill off the init process. It was all my fault. A change I made to the select emulation killed off the 'extra' timer process on atexit. Unfortunately, I didn't bother to look at the rest of the code and notice that the rock it was hiding its pid under was getting set to -1 sometimes (like when some other process sharing the memory aborted). So the code was doing a kill(-1) which means send a note to process group 1. Fixed two ways. Select is fixed and /bin/init no longer lets itself be killed so easily. --upas-favcvtvvmnigkcwskhmfvrcrut Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Dec 19 12:23:29 EST 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Dec 19 12:23:26 EST 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id D3DFD19BC7; Fri, 19 Dec 2003 12:23:25 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5594119DE9; Fri, 19 Dec 2003 12:23:11 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id ED8F419DE7; Fri, 19 Dec 2003 12:22:10 -0500 (EST) Received: from octarine.ucalgary.ca (unknown [136.159.220.105]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id BD0C319DD8 for <9fans@cse.psu.edu>; Fri, 19 Dec 2003 12:21:58 -0500 (EST) Message-ID: <2919a26ef6f18d0b1c9dc29e082a60e0@plan9.ucalgary.ca> To: 9fans@cse.psu.edu Subject: Re: [9fans] Forwarded attachment... From: mirtchov@cpsc.ucalgary.ca In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 19 Dec 2003 10:21:52 -0700 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >> This patch fixes links crashing terminals. I lost all my work from yesterday so I >> couldn't get it on the web. > > why does the kernel crash? > i'd rather fix that first. trace on a terminal that doesn't panic: octarine% acid 59461 /proc/59461/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: lstk() memcpy(p1=0x7fffed9c,p2=0x0,n=0x4,p=0x7fffed9c)+0x3e /sys/src/ape/lib/ap/386/memcpy.s:47 do_real_lookup(name=0x25531c,host=0x7fffed9c)+0x5f /usr/andrey/src/links-ape/dns.c:50 lookup_fn(name=0x25531c,h=0x13)+0x17 /usr/andrey/src/links-ape/dns.c:56 host=0x0 start_thread(ptr=0x25531c,fn=0x27bda)+0x8d /usr/andrey/src/links-ape/os_dep.c:190 p=0x11 f=0x0 do_lookup(q=0x255304,force_async=0x0)+0x49 /usr/andrey/src/links-ape/dns.c:92 do_queued_lookup(q=0x255304)+0x17 /usr/andrey/src/links-ape/dns.c:107 find_host_no_cache(name=0x25e054,data=0x2545ec,fn=0x1665e,qp=0x254634,addr=0x25e010)+0x8c /usr/andrey/src/links-ape/dns.c:186 q=0x255304 find_host(qp=0x254634,name=0x25e054,addr=0x25e010,data=0x2545ec,fn=0x1665e)+0x6d /usr/andrey/src/links-ape/dns.c:200 dnsentry=0x25dffc make_connection(c=0x2545ec,func=0x5198e,sock=0x25462c,port=0x7a7)+0x15c /usr/andrey/src/links-ape/connect.c:93 host=0x25e054 as=0x2817eb http_func(c=0x2545ec)+0x6b /usr/andrey/src/links-ape/http.c:144 run_connection(c=0x2545ec)+0x18d /usr/andrey/src/links-ape/sched.c:427 func=0x51902 hc=0x280acc try_connection(c=0x2545ec)+0x82 /usr/andrey/src/links-ape/sched.c:474 check_queue()+0x100 /usr/andrey/src/links-ape/sched.c:539 c=0x2545ec cp=0x3 d=0x113388 dd=0x2545ec check_bottom_halves()+0x76 /usr/andrey/src/links-ape/select.c:140 fn=0x7e651 data=0x0 bh=0x280acc check_timers()+0x70 /usr/andrey/src/links-ape/select.c:190 interval=0x0 t=0x25dfa4 tt=0x1 select_loop(init=0x6b90b)+0x104 /usr/andrey/src/links-ape/select.c:531 tm=0x0 tv=0x12c n=0x1 i=0x37 stbuf=0x0 main(argv=0x7fffefa4,argc=0x2)+0x41 /usr/andrey/src/links-ape/main.c:467 _main+0x26 /sys/src/ape/lib/ap/386/main9.s:12 acid: here's a snapshot of a different terminal that panicked: http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/trace.gif and the kernel image that goes with it: http://pages.cpsc.ucalgary.ca/~mirtchov/p9/9pcdisk.gz I am just assuming that the panic is triggered by the same bug in dns.c. Okamoto reported that Links doesn't panic his terminals with the dns fixed. hth, andrey --upas-favcvtvvmnigkcwskhmfvrcrut--