[9fans] Reliable 9vx(.OSX) crash

[9fans] Reliable 9vx(.OSX) crash

[a]

Do this:
	acme -c1 -f /lib/font/bit/courier/latin1.7.font /lib/kana
Put the mouse in the kana window and scroll down. For me, this
reliably crashes 9vx. Running with -t, I get:
	84 acme fault 0 no segment
	segment 0xf000000 0x10000000
	segment 0x1000 0x42000
	segment 0x42000 0x4c000
	segment 0x4c000 0x99000
	84 acme: unhandled fault va=0 [11000000] eip=3bcdd
	cpu0: registers for acme 84
	FLAGS=0 TRAP=0 ECODE=0 PC=3BCDD USP=8FF00
	  AX 00000000  BX 0008FE02  CX 00000052  DX 0008FEB0
	  SI 00000000  DI 00048646  BP 00000000
	56384: signal: sys: abort
This 9vx is post-0.12; I don't have any other systems to try 9vx
on, so I can't say if it shows up elsewhere. A recent drawterm to
an up-to-date (within ~3 days) kills acme with the following:
	stringwidth: bad character set for rune 0x0000 in /lib/font/bit/courier/latin1.7.font
	stringwidth: bad character set for rune 0x0000 in /lib/font/bit/courier/latin1.7.font
	acme: end of string in frcharofpt: '/env/mousescrollsize' file does not exist
	acme 39441: suicide: sys: trap: fault read addr=0x0 pc=0x0003bcdd
but drawterm and the cpu server are unharmed. I'm not sure,
but suspect the "/env/mousescrollsize" error is a bug; I think
it's printing the wrong error. Setting mousescrollsize changes
the error to
	acme: end of string in frcharofpt: '/lib/font/bit/courier/R.7.1.0' file does not exist
(which is true, although I'm not sure why it's looking for it;
courier/latin1.7.font just says 0x0000 to 0x00FF are in
R.7.1, which does exist).

Within 9vx, something is printed which looks like the same
message from the drawterm'd crash, but goes away before I
can be sure.
Anthony

Re: [9fans] Reliable 9vx(.OSX) crash

[Russ Cox]

> Within 9vx, something is printed which looks like the same
> message from the drawterm'd crash, but goes away before I
> can be sure.

This is just an acme font bug that causes acme to suicide.

In the latest 9vx I had left turned on the flag
that causes core dumps when 9vx panics,
but I forgot that that flag also causes 9vx to
abort when any program suicides (useful when
you suspect 9vx is the problem, not the program).
I changed the flag not to do that.

So now acme suicides but 9vx continues.

Russ

Re: [9fans] Reliable 9vx(.OSX) crash

[Fernan Bolando]

Does this also affect 9vx.Linux version. I have been testing a few
ports under it and it seems to crash in different places. I have not
been able to isolate the type of code causes it so I did not report it
on the list. It does seem to happen when I allocate a huge amount of
memory for a dense matrix. It will start slowing down and closes.

I haven't tried getting an update from hg tip. I have been trying to
avoid installing mercurial to get to the hg tip. Any chance we can get
a scheduled archive of the 9vx.* just like p9p?


On 8/1/08, Russ Cox <rsc@swtch.com> wrote:
>> Within 9vx, something is printed which looks like the same
>> message from the drawterm'd crash, but goes away before I
>> can be sure.
>
> This is just an acme font bug that causes acme to suicide.
>
> In the latest 9vx I had left turned on the flag
> that causes core dumps when 9vx panics,
> but I forgot that that flag also causes 9vx to
> abort when any program suicides (useful when
> you suspect 9vx is the problem, not the program).
> I changed the flag not to do that.
>
> So now acme suicides but 9vx continues.
>
> Russ
>
>
>


--
http://www.fernski.com

Re: [9fans] Reliable 9vx(.OSX) crash

[Russ Cox]

> Does this also affect 9vx.Linux version.

it affects linux, but not the 0.12 binaries.

> I have been testing a few
> ports under it and it seems to crash in different places. I have not
> been able to isolate the type of code causes it so I did not report it
> on the list. It does seem to happen when I allocate a huge amount of
> memory for a dense matrix. It will start slowing down and closes.
>
> I haven't tried getting an update from hg tip. I have been trying to
> avoid installing mercurial to get to the hg tip. Any chance we can get
> a scheduled archive of the 9vx.* just like p9p?

9vx is still experimental software.
if you are going to run it, i would
suggest installing mercurial.

there are still random things not
working right, both on linux and os x.
it is not as stable as i would like.

once it is more stable i will think
about making automatic archives,
but i'd really rather that for now,
regular users can update easily.

the 0.12 binaries don't have a pager,
so if you run them out of memory
they will probably crash.  if you run
with -t you can at least see the
error messages.

russ

Re: [9fans] Reliable 9vx(.OSX) crash

[Uriel]

The hg web interface can automatically provide tarballs of the latest
tip, simply add: allow_archive = bz2 zip to your
hgweb.config (there is a way to do this per-project, but I don't remember how).

For an example of how it works see http://repo.cat-v.org/hg/

uriel

On Fri, Aug 1, 2008 at 4:50 AM, Russ Cox <rsc@swtch.com> wrote:
>> Does this also affect 9vx.Linux version.
>
> it affects linux, but not the 0.12 binaries.
>
>> I have been testing a few
>> ports under it and it seems to crash in different places. I have not
>> been able to isolate the type of code causes it so I did not report it
>> on the list. It does seem to happen when I allocate a huge amount of
>> memory for a dense matrix. It will start slowing down and closes.
>>
>> I haven't tried getting an update from hg tip. I have been trying to
>> avoid installing mercurial to get to the hg tip. Any chance we can get
>> a scheduled archive of the 9vx.* just like p9p?
>
> 9vx is still experimental software.
> if you are going to run it, i would
> suggest installing mercurial.
>
> there are still random things not
> working right, both on linux and os x.
> it is not as stable as i would like.
>
> once it is more stable i will think
> about making automatic archives,
> but i'd really rather that for now,
> regular users can update easily.
>
> the 0.12 binaries don't have a pager,
> so if you run them out of memory
> they will probably crash.  if you run
> with -t you can at least see the
> error messages.
>
> russ
>
>
>