Re: [9fans] Forwarded attachment...

Re: [9fans] Forwarded attachment...

[Russ Cox]

> 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.

[9fans] Forwarded attachment...

[andrey mirtchovski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 292 bytes --]

This patch fixes links crashing terminals. I lost all my work from yesterday so I
couldn't get it on the web.

The problem isn't so bad if you have more memory (>= 512 with untouched
kernelpercent) where only links will crash. that's why we were able to debug
it yesterday...

andrey

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1116 bytes --]

I don't know whether that's the same bug, but links crashed on
nikkei.com due to a memcpy() being called with a nil second argument
in dns.c:49.  I've worked around it as follows:

	diff /n/dump/2003/1218/usr/andrey/src/links-ape/dns.c /usr/andrey/src/links-ape/dns.c
	47,48c47,49
	< 		nogethostbyaddr: if (!(hst = gethostbyname((char *)name)))
	< 			return -1;
	---
	> nogethostbyaddr:
	> 	if (!(hst = gethostbyname((char *)name)) || !hst->h_addr_list[0])
	> 		return -1;

also add this one:

	diff /n/dump/2003/1218/usr/andrey/src/links-ape/config.h /usr/andrey/src/links-ape/config.h
	22a23
	> #define HAVE_GETHOSTBYADDR 1

Can you verify if this fixes links' crashing?

The problem with nikkei not displaying proper fonts is because they're
using Shift_GIS encoding, which Links doesn't know how to handle.  I
should port lunix' "iconv" which knows everything there is to know
about encodings, and will make links use that instead of its own
(limited) conversion tables, then it'll handle Shift_JIS and many more
sites as it should.

That won't happen immediately, though...

andrey

Re: [9fans] Forwarded attachment...

[mirtchov]

>> 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

Re: [9fans] Forwarded attachment...

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 4215 bytes --]

From: mirtchov@cpsc.ucalgary.ca
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Forwarded attachment...
Date: Fri, 19 Dec 2003 10:21:52 -0700
Message-ID: <2919a26ef6f18d0b1c9dc29e082a60e0@plan9.ucalgary.ca>

>> 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