[9fans] ghostscript not finding LucidaSans

[9fans] ghostscript not finding LucidaSans

[Pietro Gagliardi]

 From an install to 9vx (built from mercurial on OS X 10.5.8) from
yesterday's CD image (though apparently some people on IRC have this
problem too):

term% man -P man
converting from troff to postscript...
reading through postscript...
Ghostscript Error:
postnote 307: sys: write on closed pipe pc=0x0001f8fc
Fontmap entry for LucidaSans ends prematurely!  Giving up.
converting from troff to postscript...
reading through postscript...
Ghostscript Error:
postnote 358: sys: write on closed pipe pc=0x0001f8fc
Fontmap entry for LucidaSans ends prematurely!  Giving up.
term% troff | page # let's try without referencing LucidaSans at all
Hello
(^d)\x04converting from troff to postscript...
reading through postscript...
Ghostscript Error:
postnote 404: sys: write on closed pipe pc=0x0001f8fc
Fontmap entry for LucidaSans ends prematurely!  Giving up.

I don't understand what's going on here but as far as I can tell /sys/
lib/postscript/fonts/LucidaSans has never existed in the Plan 9
directory tree (checking sourcesdump) and my old VM works fine without
it. Anyone know what's going on here? Thanks.

Re: [9fans] ghostscript not finding LucidaSans

[erik quanstrom]

> Ghostscript Error:
> postnote 404: sys: write on closed pipe pc=0x0001f8fc
> Fontmap entry for LucidaSans ends prematurely!  Giving up.
>
> I don't understand what's going on here but as far as I can tell /sys/
> lib/postscript/fonts/LucidaSans has never existed in the Plan 9
> directory tree (checking sourcesdump) and my old VM works fine without
> it. Anyone know what's going on here? Thanks.

no, it never did.

	 ; find /sys/lib|grep 'LucidaSans$'
	/sys/lib/postscript/troff/LucidaSans
	/sys/lib/troff/font/devutf/LucidaSans

i can't reproduce your results:

	ladd; bind -b /n/sources/plan9/386/bin /bin
	ladd; bind -b /n/sources/plan9/rc/bin /bin
	ladd; bind /n/sources/plan9/lib /lib
	ladd; bind /n/sources/plan9/sys /sys
	ladd; ramfs
	ladd; mkdir /tmp/x
	ladd; bind /tmp/x /sys/lib/lp/log
	ladd; touch /tmp/x/stdout; chmod +a /tmp/x/stdout
	ladd; echo hello | troff | page

- erik

Re: [9fans] ghostscript not finding LucidaSans

[Pietro Gagliardi]

On Jun 27, 2010, at 9:56 PM, erik quanstrom wrote:
> i can't reproduce your results:
Huh. Using your suggested command line I get the following:

converting from troff to postscript...
/tmp/lp174: rc (generic): can't open: '/tmp/lp174' permission denied
reading through postscript...
cannot find end of first line

I'm not sure if this has to do with 9vx... in fact I'm not sure
exactly what's causing these things to behave as they are now. What I
can say is that to set this environment up I just copied the contents
of the Plan 9 CD to a folder, put the built-from-source 9vx into that
folder, logged in as glenda, ran
	mkdir /usr/pietro
(since fscons obviously isn't there), logged in as pietro, and ran
	/sys/lib/newuser

Re: [9fans] ghostscript not finding LucidaSans

[erik quanstrom]

> On Jun 27, 2010, at 9:56 PM, erik quanstrom wrote:
> > i can't reproduce your results:
> Huh. Using your suggested command line I get the following:

guess i forgot the "bind /tmp /sys/lib/lp/tmp".  lp is
pretty complicated.

- erik

Re: [9fans] ghostscript not finding LucidaSans

[Pietro Gagliardi]

On Jun 28, 2010, at 12:40 AM, erik quanstrom wrote:
> guess i forgot the "bind /tmp /sys/lib/lp/tmp".  lp is
> pretty complicated.
>
> - erik
>

Thanks, now it worked. I decided to investigate the issue further with
what you gave me and I found that all I needed to get it to work was the
	bind /n/sources/plan9/sys /sys
and further constrained that to
	bind /n/sources/plan9/sys/lib/postscript/ /sys/lib/postscript/
However, overwriting my /sys/lib/postscript with the one from sources
did not fix the problem. Is there some fundamental difference between
binding and copying that I'm overlooking or just some weird behavior
in ghostscript that is causing this to happen?

The diff output from comparing the two directories:

diff /sys/lib/postscript//troff/HX /n/sources/plan9/sys/lib/
postscript//troff/HX
1c1
< 0x0000 0x00ff Helvetica-Narrow-BoldOblique
---
 > 0x0000 0x00ff Helvetica-BoldOblique
Only in /n/sources/plan9/sys/lib/postscript//troff: Hx

Re: [9fans] ghostscript not finding LucidaSans

[Pietro Gagliardi]

Actually, on further investigation it turns out while dircp /n/sources/
plan9/sys/lib/postscript dir works fine, diff -r dir /n/sources/plan9/
sys/lib/postscript gives me the same diff log, and diff -r dir olddir
tells me they're identical. So what's going on here...

Re: [9fans] ghostscript not finding LucidaSans

[Ethan Grammatikidis]

On 28 Jun 2010, at 04:18, Pietro Gagliardi wrote:

> I'm not sure if this has to do with 9vx... in fact I'm not sure
> exactly what's causing these things to behave as they are now.

I have the same problem with postscript, and wonder if something went
wrong in getting the files from Plan 9 to make a 9vx tree. I ran a
single Plan 9 instance in Qemu for a few years; no trouble with
postscript then. I copied the tree out from the live running system
using tar and dial[*] on the plan 9 side; tar and netcat on the unix,
and used that tree with no further modification as a root for 9vx.
Postscript now fails with the error Pietro gave.

[*] dial as in p9p / inferno's dial command. I renamed the binary to
dialout to avoid conflict with /bin/dial/

Re: [9fans] ghostscript not finding LucidaSans

[erik quanstrom]

On Mon Jun 28 02:37:21 EDT 2010, pietro10@mac.com wrote:
> Actually, on further investigation it turns out while dircp /n/sources/
> plan9/sys/lib/postscript dir works fine, diff -r dir /n/sources/plan9/
> sys/lib/postscript gives me the same diff log, and diff -r dir olddir
> tells me they're identical. So what's going on here...

the difference that i can think of is #Z.  #Z doesn't do
locks, exclusive access, etc.  why don't you try binding a ramfs
/tmp on lp's temp directory, /sys/lib/lp/tmp.  if that's not
it, the bind/mount list you used to get things working from
sources should give you more directories to investigate.

- erik

Re: [9fans] ghostscript not finding LucidaSans

[Pietro Gagliardi]

On Jun 28, 2010, at 9:09 AM, erik quanstrom wrote:

> On Mon Jun 28 02:37:21 EDT 2010, pietro10@mac.com wrote:
>> Actually, on further investigation it turns out while dircp /n/
>> sources/
>> plan9/sys/lib/postscript dir works fine, diff -r dir /n/sources/
>> plan9/
>> sys/lib/postscript gives me the same diff log, and diff -r dir olddir
>> tells me they're identical. So what's going on here...
>
> the difference that i can think of is #Z.  #Z doesn't do
> locks, exclusive access, etc.  why don't you try binding a ramfs
> /tmp on lp's temp directory, /sys/lib/lp/tmp.  if that's not
> it, the bind/mount list you used to get things working from
> sources should give you more directories to investigate.
>
> - erik
>

That didn't work. I narrowed the directory discrepancies to /sys/lib/
postscript/font but not to any of its subdirectories. However again,
copying from sources and overwriting what's already there did nothing,
even if I had removed the directory from the host machine already. I
also tried to overwrite with a copy of the directory tree from an ISO
downloaded today, but that didn't work either (however both ISOs
appear to come from June 26, so I dunno). Only binding did the trick.

Re: [9fans] ghostscript not finding LucidaSans

[ron minnich]

well, once again, ratrace can be a good tool for understanding things
that don't make sense. I use it all the time for this type of problem
and the results are frequently illuminating.

ron

[9fans] problems with tracing 9vx on os x (was: Re: ghostscript not finding LucidaSans

[Pietro Gagliardi]

On Jun 28, 2010, at 11:04 AM, ron minnich wrote:
> well, once again, ratrace can be a good tool for understanding things
> that don't make sense. I use it all the time for this type of problem
> and the results are frequently illuminating.
>
> ron
>


First I found a slight building problem on Mac OS X 10.5.8: ethertap.c
needs to be changed to include <sys/socket.h> before <net/if.h> and to
add a defined(__MACOSX__) or similar to the #elf defined(__FreeBSD__)
so opentap() can be defined.

However once this version was built, I got the following right after
seeing the memory usage statistic line:

9vx panic: user fault: signo=10 addr=1100cc77 [useraddr=cc77] read=1
eip=b7de5 esp=2e93ece0
sleeping, so you can attach gdb to pid 44257

Re: [9fans] problems with tracing 9vx on os x (was: Re: ghostscript not finding LucidaSans

[yy]

2010/6/28 Pietro Gagliardi <pietro10@mac.com>:
> First I found a slight building problem on Mac OS X 10.5.8: ethertap.c needs
> to be changed to include <sys/socket.h> before <net/if.h> and to add a
> defined(__MACOSX__) or similar to the #elf defined(__FreeBSD__) so opentap()
> can be defined.
>
> However once this version was built, I got the following right after seeing
> the memory usage statistic line:


ethertap is part of the modifications I'm doing to 9vx as part of my
gsoc project. Since I don't have any machine running OS X, the darwin
version is far behind the linux one. I compile 9vx in FreeBSD from
time to time, but running it is another history. Eventually I'd like
to do something about this. For the time being, you can fill an issue
at http://bitbucket.org/yiyus/vx32/ or, even better, send me a patch.

By the way, you should be able to deactivate compilation of the tap
(or pcap) ether device with the variable PLAN9TAP (PLAN9PCAP) in
Makefrag.

--
- yiyus || JGL . 4l77.com

Re: [9fans] problems with tracing 9vx on os x (was: Re: ghostscript not finding LucidaSans

[Pietro Gagliardi]

On Jun 29, 2010, at 4:03 AM, yy wrote:
> By the way, you should be able to deactivate compilation of the tap
> (or pcap) ether device with the variable PLAN9TAP (PLAN9PCAP) in
> Makefrag.

Okay, I did so but I still get the crash as before. Here's a gdb
backtrace:

#0  0x919366fa in select$DARWIN_EXTSN ()
#1  0x0000fc75 in microdelay (x=1000000) at 9vx/time.c:389
#2  0x0000db9c in dt_panic (fmt=0xbd5cc "user fault: signo=%d addr=%p
[useraddr=%p] read=%d eip=%p esp=%p") at 9vx/stub.c:536
#3  0x0000a886 in sigsegv (signo=10, info=0x5e1fc0, v=0x5e1d20) at 9vx/
main.c:844
#4  0x00013b5c in wrapper (siginfo=0x5e1fc0, mcontext=0x5e1d60,
handler=0xa769 <sigsegv>) at 9vx/osx/signal.c:85
#5  0x000b6e09 in xscan (p=0x63f3a0) at libvx32/emu.c:247
#6  0x000b9bda in xlate (vxp=0x63f3a0) at libvx32/emu.c:1695
#7  0x000b9e7e in vxproc_run (vxp=0x63f3a0) at libvx32/emu.c:1841
#8  0x0001373f in touser (initsp=0xfffffa4) at 9vx/vx32.c:251
#9  0x0000a762 in init0 () at 9vx/main.c:742

I'm not sure what this information would give you, but...