Giter Site home page Giter Site logo

9fans / plan9port Goto Github PK

View Code? Open in Web Editor NEW
1.6K 115.0 318.0 25.61 MB

Plan 9 from User Space

Home Page: https://9fans.github.io/plan9port/

License: Other

Makefile 0.59% Shell 1.16% Perl 0.01% Awk 0.04% HTML 0.14% C 92.01% JavaScript 0.10% C++ 1.29% TeX 0.25% PostScript 0.91% Objective-C 0.33% Assembly 0.21% Smalltalk 0.19% Coq 0.07% Batchfile 0.01% Yacc 1.24% Lex 0.06% Roff 1.39% MATLAB 0.01% sed 0.01%

plan9port's Introduction

This is a port of many Plan 9 libraries and programs to Unix.

Installation

To install, run ./INSTALL. It builds mk and then uses mk to run the rest of the installation.

For more details, see install(1), at install.txt in this directory and at https://9fans.github.io/plan9port/man/man1/install.html.

Documentation

See https://9fans.github.io/plan9port/man/ for more documentation. (Documentation is also in this tree, but you need to run a successful install first. After that, "9 man 1 intro".)

Intro(1) contains a list of man pages that describe new features or differences from Plan 9.

Helping out

If you'd like to help out, great!

If you port this code to other architectures, please share your changes so others can benefit.

Git

You can use Git to keep your local copy up-to-date as we make changes and fix bugs. See the git(1) man page here ("9 man git") for details on using Git.

Status

Github Actions Build Status Coverity Scan Build Status

Contact

plan9port's People

Contributors

0intro avatar 1g0rb0hm avatar 4ad avatar ality avatar bhuntsman avatar ejsherry avatar fawlty avatar fhs avatar grai avatar igorburago avatar jacobvosmaer avatar jxy avatar knieriem avatar markvanatten avatar millerresearch avatar minux avatar mkhl avatar mmnmnnmnmm avatar mpl avatar nmeum avatar nsajko avatar phonologus avatar raylai avatar robpike avatar rsc avatar sevan avatar swasey avatar trisk avatar vat9 avatar xiw avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

plan9port's Issues

gdb fails to start in acme

I have trouble starting gdb in acme if you just do 'gdb' in acme you get an immediate quit command, stracing the terminal against acme gives me this, seems ioctl fails in the acme case for some reason
If I start acme in a win window, then it opens without quitting instantly, but hangs whenever I try to use it debugging a program, ie:
(
open win
gdb /bin/ls
gdb> r
)
this hangs for me.

I attached the strace output of the first case where you try to start gdb in acme without using win.

==== acme =====
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=0, events=POLLIN}], 3, 0) = 1 ([{fd=0, revents=POLLIN}])
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffbecc3a10) = -1 ENOTTY (Inappropriate ioctl for device)
read(0, "", 1) = 0
rt_sigaction(SIGTSTP, {0x5cff40, [TSTP], SA_RESTORER|SA_RESTART, 0x7f3ee331ecb0}, {SIG_DFL, [], 0}, 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffbecc39f0) = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
rt_sigaction(SIGINT, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f3ee331ecb0}, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f3ee331ecb0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f3ee410e940}, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f3ee331ecb0}, 8) = 0
write(1, "quit\n", 5quit
) = 5
exit_group(0) = ?
+++ exited with 0 +++

==================== from terminal =================
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGINT, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f4854d4ecb0}, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f4854d4ecb0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
ioctl(0, TIOCGWINSZ, {ws_row=53, ws_col=189, ws_xpixel=1890, ws_ypixel=954}) = 0
ioctl(0, SNDRV_TIMER_IOCTL_STATUS or TIOCSWINSZ, {ws_row=53, ws_col=189, ws_xpixel=1890, ws_ypixel=954}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
rt_sigaction(SIGINT, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {0x5d0050, [INT], SA_RESTORER|SA_RESTART, 0x7f4854d4ecb0}, 8) = 0
rt_sigaction(SIGTERM, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {0x5d0210, [TERM], SA_RESTORER|SA_RESTART, 0x7f4854d4ecb0}, 8) = 0
rt_sigaction(SIGQUIT, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {0x5cff20, [QUIT], SA_RESTORER|SA_RESTART, 0x7f4854d4ecb0}, 8) = 0
rt_sigaction(SIGALRM, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTTOU, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTTIN, {0x6d0660, [], SA_RESTORER, 0x7f4855b3e940}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x6cfd80, [], SA_RESTORER|SA_RESTART, 0x7f4855b3e940}, {0x4f8ad0, [], SA_RESTORER, 0x7f4855b3e940}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
write(1, "(gdb) ", 6(gdb) ) = 6
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=0, events=POLLIN}], 3, 0) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=0, events=POLLIN}], 3, 4294967295Process 1781 detached

am porting to minix3?

can plan9port be ported to a platform with out pthreads?
(minix3)

what I am seeking is to get acme ported to minix3.

any pointers?

Inconsistent sam cursor (Yosemite)

Steps to reproduce under Yosemite (Cocoa retina build):

  • Select new, zerox, resize, close or write from the button 3 menu
  • Move the pointer around the sam window without clicking

The cursor alternates between the default system pointer (black arrow) and the appropriate sam cursor.

9pfuse: Support for TFLUSH messages

Currently 9pfuse doens't handle FUSE_INTERRUPT opcode requests, and without it TFLUSH messages aren't sent to file servers. There are some way to get TFLUSH messages being sent to file server with 9pfuse?

Delete key on OS X version of Acme Editor doesn't in fact delete

Steps to reproduce:

  • From terminal, type acme -al
  • mouse over to a window or title bar.
  • hit the delete key

Expected:

  • forward delete behaviour as is standard across all other applications

Result:

  • prints a strange unicode icon

Context:
Some research into the matter turned up this PDF (http://www.quanstro.net/newbie-guide.pdf) that indicated that the Delete key is mapped to stopping processes, much in the way that Ctrl-C does in traditional UNIX.

I have not seen any benefit to printing this unicode icon when editing text files. I would like to suggest that a compiler flag be added to give users the opportunity to remap the Delete key to forward delete.

Thank you! I really appreciate all the work being done on this project and use the editor every day.

cmd/acme: Alt button "sticks" sometimes after commit c1bd38a

This was first reported on bitbucket (issue #128), and it is still an issue on a fresh INSTALL as of commit 08e7937.

Quoting from the original issue report:

After applying commit c1bd38a Acme sometimes has issues with Alt key "sticking". From my observations it often happens after returning to Acme from other windows. Clicking mouse B1 behaves as B2. Pushing and releasing Alt key while Acme window is active fixes the problem but it can return later after switching to another window and returning to Acme.

Applying the patch mentionned in the bitbucket issue comments does not fix the problem for me.

acme: crash on osx in openfont

backtrace:

[jacekm@jacekm-mbp cores]$ lldb -c core.627 /src/9fans.net/plan9port/bin/acme
(lldb) target create "/src/9fans.net/plan9port/bin/acme" --core "core.627"
warning: (x86_64) /cores/core.627 load command 121 LC_SEGMENT_64 has a fileoff + filesize (0x20639000) that extends beyond the end of the file (0x20638000), the segment will be truncated to match
warning: (x86_64) /cores/core.627 load command 122 LC_SEGMENT_64 has a fileoff (0x20639000) that extends beyond the end of the file (0x20638000), ignoring this section
Core file '/cores/core.627' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x0000000106ee4f57 acme`openfont(d=0x00007fca78600180, name=0x00007fca7a609290) + 71 at openfont.c:224, stop reason = signal SIGSTOP
    frame #0: 0x0000000106ee4f57 acme`openfont(d=0x00007fca78600180, name=0x00007fca7a609290) + 71 at openfont.c:224
   221          *p = '\0';
   222
   223      f = openfont1(d, name);
-> 224      f->lodpi = f;
   225      f->namespec = namespec;
   226
   227      /* add to display list for when dpi changes */
  thread #2: tid = 0x0001, 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff91ec6136:  jae    0x7fff91ec6140            ; __psynch_cvwait + 20
   0x7fff91ec6138:  movq   %rax, %rdi
   0x7fff91ec613b:  jmp    0x7fff91ec1c53            ; cerror_nocancel
   0x7fff91ec6140:  retq
  thread #3: tid = 0x0002, 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff91ec6136:  jae    0x7fff91ec6140            ; __psynch_cvwait + 20
   0x7fff91ec6138:  movq   %rax, %rdi
   0x7fff91ec613b:  jmp    0x7fff91ec1c53            ; cerror_nocancel
   0x7fff91ec6140:  retq
  thread #4: tid = 0x0003, 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff91ec7682:  jae    0x7fff91ec768c            ; read + 20
   0x7fff91ec7684:  movq   %rax, %rdi
   0x7fff91ec7687:  jmp    0x7fff91ec1c78            ; cerror
   0x7fff91ec768c:  retq
  thread #5: tid = 0x0004, 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff91ec7682:  jae    0x7fff91ec768c            ; read + 20
   0x7fff91ec7684:  movq   %rax, %rdi
   0x7fff91ec7687:  jmp    0x7fff91ec1c78            ; cerror
   0x7fff91ec768c:  retq
  thread #6: tid = 0x0005, 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff91ec7682:  jae    0x7fff91ec768c            ; read + 20
   0x7fff91ec7684:  movq   %rax, %rdi
   0x7fff91ec7687:  jmp    0x7fff91ec1c78            ; cerror
   0x7fff91ec768c:  retq
  thread #7: tid = 0x0006, 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec7682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff91ec7682:  jae    0x7fff91ec768c            ; read + 20
   0x7fff91ec7684:  movq   %rax, %rdi
   0x7fff91ec7687:  jmp    0x7fff91ec1c78            ; cerror
   0x7fff91ec768c:  retq
  thread #8: tid = 0x0007, 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec6136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff91ec6136:  jae    0x7fff91ec6140            ; __psynch_cvwait + 20
   0x7fff91ec6138:  movq   %rax, %rdi
   0x7fff91ec613b:  jmp    0x7fff91ec1c53            ; cerror_nocancel
   0x7fff91ec6140:  retq
  thread #9: tid = 0x0008, 0x00007fff91ec691a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec691a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff91ec691a:  jae    0x7fff91ec6924            ; __wait4_nocancel + 20
   0x7fff91ec691c:  movq   %rax, %rdi
   0x7fff91ec691f:  jmp    0x7fff91ec1c53            ; cerror_nocancel
   0x7fff91ec6924:  retq
  thread #10: tid = 0x0009, 0x00007fff91ec691a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91ec691a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff91ec691a:  jae    0x7fff91ec6924            ; __wait4_nocancel + 20
   0x7fff91ec691c:  movq   %rax, %rdi
   0x7fff91ec691f:  jmp    0x7fff91ec1c53            ; cerror_nocancel
   0x7fff91ec6924:  retq
(lldb) bt
* thread #1: tid = 0x0000, 0x0000000106ee4f57 acme`openfont(d=0x00007fca78600180, name=0x00007fca7a609290) + 71 at openfont.c:224, stop reason = signal SIGSTOP
  * frame #0: 0x0000000106ee4f57 acme`openfont(d=0x00007fca78600180, name=0x00007fca7a609290) + 71 at openfont.c:224
    frame #1: 0x0000000106eb7c71 acme`rfget(fix=1, save=0, setfont=0, name=<unavailable>) + 161 at acme.c:893
    frame #2: 0x0000000106ec2011 acme`fontx(et=<unavailable>, t=<unavailable>, argt=<unavailable>, _0=<unavailable>, _1=<unavailable>, arg=<unavailable>, narg=0) + 529 at exec.c:1206
    frame #3: 0x0000000106ec348a acme`execute(t=0x00007fca788088c0, aq0=<unavailable>, aq1=<unavailable>, external=<unavailable>, argt=0x0000000000000000) + 570 at exec.c:240
    frame #4: 0x0000000106ed9412 acme`xfideventwrite(x=0x00007fca785002c0, w=0x00007fca78808800) + 530 at xfid.c:878
    frame #5: 0x0000000106ed83fb acme`xfidwrite(x=0x00007fca785002c0) + 923 at xfid.c:572
    frame #6: 0x0000000106ed6b41 acme`xfidctl(arg=0x00007fca785002c0) + 65 at xfid.c:51
    frame #7: 0x0000000106eeddea acme`threadstart(y=<unavailable>, x=<unavailable>) + 26 at thread.c:96
(lldb)

cmdline:

"-a"
"-f" "/mnt/font/Avenir-Heavy/20a/font,/mnt/font/Avenir-Heavy/35a/font"
"-F" "/mnt/font/Menlo-Regular/18a/font,/mnt/font/Menlo-Regular/31a/font"
"-W" "1800x1200"

env:

TERM=dumb
mousescrollsize=1

repro:
B2-click 'Font non-existent-font-name' in any window

Plumb.app doesn't work...

That's basically as far as I can get on this one. At one time, I had Plumb.app as the default program to handling open text files when I double-clicked on them in Finder. For a few months now, it hasn't worked, even when I completely deleted the p9p tools and re-installed from scratch. I don't get any error messages. If I run the binary that is within Plumb.app from the command line, everything works successfully, but even a script that wraps this binary doesn't execute successfully when it is used as the default app to open files within iTerm2.

I'm at a loss on this one...

OS X 10.11.1
p9p commit 44eb208
iTerm2 nightly build

Best,
Rob

Build Warnings

>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/eqn; mk all
9c  input.c
   fgets(ebuf, sizeof ebuf, curfile->fin);
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  fossil.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9p.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9auth.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9dir.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9excl.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9fid.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9fsys.c
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
>>> cd /home/j/dev/apps/plan9/plan9port/src/cmd/fossil; mk all
9c  9lstn.c

acme does not dump when window is closed

Writing in deep frustration because I accidentally closed
a window and lost hours of work. This has happened before.

Under Ubuntu at any rate, closing an acme window
does not dump current state to $HOME/acme.dump. It should.

caddr_t not typedefed in sendfd.c

This is just a first error. The next one, when I manually include

typedef char* caddr_t;

is in Linux.c, "storage size of ifr not known", which seems related.

I know I possibly need a debian dev package for this or a configured kernel. But I already installed the linux-libc-dev and the linux-kernel-headers.

For a gentoo user it's quite hard to guess what build time dependencies a debian system might need and how the packages might be named that are needed to get the system set up right for building.

I assume it has something to do with kernel configuration. But I would like to install the needed files from debian packages, if possible.

setting addr to dot(.) does not work

Expected behavior:
Be able to write an addr that includes dot to the addr file and be able to read xdata to get the selection.

#example
echo -n .,$ | 9p write acme/$winid/addr
9p read acme/$winid/xdata

Actual behavior:
The results are random, most of the time xdata is empty. Sometimes it holds the expected results, other times it is a random selection.

Button three respects the dot (.) symbol when part of an address. For example:

/path/to/my/file:.,$

if the file is open then it will select from the beginning of dot to the end of the file.

According to the docs addr should respect it as well.

It could be useful to quickly get a byte offset set addr to 0,. and read xdata and count the bytes. I know there are other ways to do this. Just mentioning a use case.

9term: pasted buffer does not show when reading stdin

If you paste something on a 9term while a program is reading STDIN, the value will be pasted but won't be shown on the terminal. The bug does not happen if something was previously typed manually before pasting.

How to reproduce:

  • open 9term
  • type the cat command and ENTER
  • copy any text to the clipboard
  • paste to 9term

The text won't show on the terminal. But it is there, and if you press ENTER cat will echo it. Also, if you type anything after you started the program reading STDIN but before pasting, then the pasted text will show normally.

Tested on openbsd 5.9, under both fvwm, rio and dwm window managers. Using ksh shell.

Segfault on Font

I have fontsrv running. Some of the fonts have spaces in them. If I try to execute:

Font /mnt/font/Courier New/12a/font

I get a segfault. But the following works as expected:

Font /mnt/font/Ubuntu/12a/font

Like elsewhere in acme, you can't have a space in a path.

acme: Kcmd not being passed through on linux

Can't trigger copy or paste via keyboard with any combination of ctrl + alt + windows key.

From the code it looks like windows key is the correct combination.

When I add printf("key - %d\n", r); @

I get
key - 99 // When pressing c
key - 3 // When pressing Ctrl + c
key - 99 // When pressing Windows key + c
key - 99 // When pressing alt + c (the keypress is sometimes ignored)

cmd/acme: crash in look3

[jacekm@jacekm-mbp cores]$ lldb -c core.41319 $(which acme)
(lldb) target create "/src/9fans.net/plan9port/bin/acme" --core "core.41319"
warning: (x86_64) /cores/core.41319 load command 141 LC_SEGMENT_64 has a fileoff + filesize (0x209d1000) that extends beyond the end of the file (0x209d0000), the segment will be truncated to match
warning: (x86_64) /cores/core.41319 load command 142 LC_SEGMENT_64 has a fileoff (0x209d1000) that extends beyond the end of the file (0x209d0000), ignoring this section
Core file '/cores/core.41319' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff89260286:  jae    0x7fff89260290            ; __pthread_kill + 20
   0x7fff89260288:  movq   %rax, %rdi
   0x7fff8926028b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260290:  retq
  thread #2: tid = 0x0001, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #3: tid = 0x0002, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #4: tid = 0x0003, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #5: tid = 0x0004, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #6: tid = 0x0005, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #7: tid = 0x0006, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #8: tid = 0x0007, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #9: tid = 0x0008, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #10: tid = 0x0009, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #11: tid = 0x000a, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #12: tid = 0x000b, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #13: tid = 0x000c, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #14: tid = 0x000d, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
(lldb) bt
* thread #1: tid = 0x0000, 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff92ede9f9 libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff95a5aa53 libsystem_c.dylib`__abort + 145
    frame #3: 0x00007fff95a5b331 libsystem_c.dylib`__stack_chk_fail + 197
    frame #4: 0x000000010d700e27 acme`look3(t=<unavailable>, q0=<unavailable>, q1=<unavailable>, external=<unavailable>) + 1639 at look.c:233
    frame #5: 0x000000010d712441 acme`xfideventwrite(x=0x00007fdaf4000cc0, w=0x00007fdaf284c400) + 497 at xfid.c:882
    frame #6: 0x000000010d71144b acme`xfidwrite(x=0x00007fdaf4000cc0) + 923 at xfid.c:572
    frame #7: 0x000000010d70fb91 acme`xfidctl(arg=0x00007fdaf4000cc0) + 65 at xfid.c:51
    frame #8: 0x000000010d726dea acme`threadstart(y=<unavailable>, x=<unavailable>) + 26 at thread.c:96
(lldb)

cmd/acme win doesn't work

I've recently started using acme, having cloned from 44eb208. On both OS X and Linux (Arch and Ubuntu 12.04), executing the win command does open a new window, but there is no prompt and entering commands has no effect; it functions like a normal file window. I've tried running plumber, but this has no effect.

Segmentation fault with mailfs

I try to run mailfs to read mails. When run with -VD the IMAP connection works, before the crash all my mails are displayed and mailfs ends with <| # OK Fetch completed. Segmentation fault (core dumped)
After a clean install of plan9port-git on ArchLinux:

$ uname -a
Linux 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux
$ plumber
$ 9p ls plumb
edit
image
msword
openoffice
postscript
rules
seemail
send
sendmail
showmail
web
$ factotum
$ gdb mailfs
(...)
(gdb) run -t -u xash posteo.de
Starting program: /usr/lib/plan9/bin/mailfs -t -u username server
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

!adding key: proto=pass role=client service=imap server=posteo.de user=xash
password: 
!

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff76c6609 in raise () from /usr/lib/libpthread.so.0
(gdb) where
#0  0x00007ffff76c6609 in raise () from /usr/lib/libpthread.so.0
#1  0x0000000000411e04 in child ()
#2  0x000000000041205e in _threadsetupdaemonize ()
#3  0x0000000000411d0d in p9main ()
#4  0x0000000000402779 in main ()

$ strace mailfs -t -u xash posteo.de
execve("/usr/lib/plan9/bin/mailfs", ["mailfs", "-t", "-u", "xash", "posteo.de"], [/* 32 vars */]) = 0
brk(0)                                  = 0x1031000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=151822, ...}) = 0
mmap(NULL, 151822, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f867c820000
close(3)                                = 0
open("/usr/lib/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20U\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1067384, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f867c81f000
mmap(NULL, 3162456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f867c320000
mprotect(0x7f867c423000, 2097152, PROT_NONE) = 0
mmap(0x7f867c623000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x103000) = 0x7f867c623000
close(3)                                = 0
open("/usr/lib/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=10616, ...}) = 0
mmap(NULL, 2105624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f867c11d000
mprotect(0x7f867c11f000, 2093056, PROT_NONE) = 0
mmap(0x7f867c31e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f867c31e000
close(3)                                = 0
open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340`\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142912, ...}) = 0
mmap(NULL, 2213136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f867bf00000
mprotect(0x7f867bf18000, 2093056, PROT_NONE) = 0
mmap(0x7f867c117000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f867c117000
mmap(0x7f867c119000, 13584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f867c119000
close(3)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1984880, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f867c81e000
mmap(NULL, 3813008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f867bb5d000
mprotect(0x7f867bcf6000, 2097152, PROT_NONE) = 0
mmap(0x7f867bef6000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x199000) = 0x7f867bef6000
mmap(0x7f867befc000, 16016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f867befc000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f867c81d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f867c81c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f867c81b000
arch_prctl(ARCH_SET_FS, 0x7f867c81c700) = 0
mprotect(0x7f867bef6000, 16384, PROT_READ) = 0
mprotect(0x7f867c117000, 4096, PROT_READ) = 0
mprotect(0x7f867c31e000, 4096, PROT_READ) = 0
mprotect(0x7f867c623000, 4096, PROT_READ) = 0
mprotect(0x7f867c846000, 4096, PROT_READ) = 0
munmap(0x7f867c820000, 151822)          = 0
set_tid_address(0x7f867c81c9d0)         = 17650
set_robust_list(0x7f867c81c9e0, 24)     = 0
rt_sigaction(SIGRTMIN, {0x7f867bf05bb0, [], SA_RESTORER|SA_SIGINFO, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f867bf05c40, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f867bf10740}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
pipe([3, 4])                            = 0
dup2(3, 28)                             = 28
dup2(4, 29)                             = 29
close(3)                                = 0
close(4)                                = 0
fcntl(28, F_SETFD, FD_CLOEXEC)          = 0
fcntl(29, F_SETFD, FD_CLOEXEC)          = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, {0x411e40, [CHLD], SA_RESTORER|SA_RESTART, 0x7f867bb90540}, {SIG_DFL, [], 0}, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f867c81c9d0) = 17651
close(29)                               = 0
rt_sigaction(SIGHUP, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGILL, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGTRAP, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGABRT, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGBUS, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGFPE, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGSEGV, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGCHLD, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGSTOP, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = -1 EINVAL (Invalid argument)
rt_sigaction(SIGURG, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGXCPU, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGXFSZ, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGVTALRM, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGPROF, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGIO, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGPWR, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
rt_sigaction(SIGSYS, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, NULL, 8) = 0
read(28, "", 19)                        = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
wait4(17651, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], 0, NULL) = 17651
setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [SEGV], SA_RESTORER|SA_RESTART, 0x7f867bb90540}, {0x411e40, [], SA_RESTORER|SA_RESTART, 0x7f867bf10740}, 8) = 0
tgkill(17650, 17650, SIGSEGV)           = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=17650, si_uid=1000} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

plot produces no output on El Capitan

Does anyone here use the plot command? It runs, but produces no output. Minimizing and re-maximizing the window has no effect. Forcing it to full-screen changes the gray background to white and the menu now appears when one right clicks, whereas it didn't appear when the window was initially opened. Not sure about what could be wrong here. For comparison, cmapcube runs just fine.

Also, is it possible to save the final output from plot to a file for later viewing? That would be really helpful.

missing frand()

rand(3) describes frand(), but when i tried to compile, i get an undefined reference to p9frand.

Sam shows error message when closed

On my Ubuntu 14.04 x64 system, I get this in my terminal when I close Sam:

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 154 requests (154 known processed) with 0 events remaining.

Probably not important but slightly disturbing.

cmd/acme: new pane affects a selection-in-progress

How to reproduce:

  1. Execute 'sleep 5 && echo foo'.
  2. Start a selection in one of the existing panes: keep mouse 1 pressed (don't release).
  3. Wait 5 seconds for the new window to appear. Ensure not to move the mouse.
  4. Move the mouse. The selection resulting from this move will be much larger than expected.

The surprise at step 4 is clearly a result of the new window appearing. It seems like mouse repositioning should be disabled while 1 is pressed (and potentially other buttons too).

[acme] Missing pixel(s)

(Linux)

  1. Open acme
  2. Click on New tag
  3. Click anywhere on the tag field, for example, after Look tag
    (in the body field, press Enter (to pull cursor down) - the (missing) pixels are easier visible)
    (I think two pixels are missing)
    image1

If Enter is pressed, the pixels reappear:
image2

also, if Backspace is pressed when cursor is here:
image3

returns the pixels for the moment:
image4

pressing anything (Space etc.) removes them.

9term launches child process with SIGCHLD blocked [linux]

src/cmd/9term/rcstart.c

rcstart() forks a child process to exec the shell. Before the exec there are two calls like sys("stty ...").

sys() ends up calling notedisable("sys: child"), which blocks SIGCHLD via sigprocmask(). However, there is no corresponding call to noteenable(), so at the time of exec() SIGCHLD is still blocked. The signal mask is not reset on exec, which causes problems for programs that expect to receive SIGCHLD but don't explicitly unblock the signal.

For a concrete example, running 9term gdb 9p and then executing start at the gdb prompt just hangs. If I insert a wrapper program that unblocks SIGCHLD and execs its args, 9term unblkchld gdb 9p, then executing start at the gdb prompt causes execution to stop when 9p enters main(), as expected.

Graphical applications fail to start on GNU / Linux (ARM)

Hi,

I compiled Plan 9 from User Space on the Open Pandora, a gaming handheld running GNU / Linux (ARM).

Release thread: https://pyra-handheld.com/boards/threads/plan-9-from-user-space.65064/#post-1388455

Package: http://repo.openpandora.org/?page=detail&app=plan9port-magicsam

Command line only tools work perfectly, but graphical applications (9term, acme, etc...) fail with the following error message:

usage: devdraw (don't run directly)
acme: can't open display: muxrpc: unexpected eof

I browsed the web yesterday, and found that missing X11 development libraries may cause this issue. I checked, and libX11-devel, libXt-devel and libXext-devel are part of my development environment, so this can't be the root cause.

Could you please have a look at it ?

Cheers, Sam a.k.a Magic Sam from the Open Pandora community

fontsrv build fail on Linux

version: b3a110a

st% mk
9c -I/usr/include -I/usr/include/freetype2 x11.c
x11.c:107:9: error: ‘xf’ redeclared as different kind of symbol
XFont *xf, *xfp, *xfe;
^
x11.c:105:18: note: previous definition of ‘xf’ was here
mksubfont(XFont *xf, char *name, int lo, int hi, int size, int antialias)
^
x11.c:107:20: warning: unused variable ‘xfe’ [-Wunused-variable]
XFont *xf, *xfp, *xfe;
^
x11.c:107:14: warning: unused variable ‘xfp’ [-Wunused-variable]
XFont *xf, *xfp, *xfe;
^
mk: 9c -I/usr/include -I/usr/include/freetype2 x11.c : exit status=exit(1)

imageinit: can't open font

The fonts in /usr/lib/plan9 work. Running under Linux/X11.

[user@Firemagic ~]$ fontsrv & 
[1] 2631
[user@Firemagic ~]$ Fontconfig error: "/home/user/.config/fontconfig/fonts.conf", line 1: XML or text declaration not at start of entity
Fontconfig error: "/home/user/.config/fontconfig/fonts.conf", line 1: XML or text declaration not at start of entity

[user@Firemagic ~]$ 9p ls font/Ubuntu
10
10a
11
11a
12
12a
13
13a
14
14a
15
15a
16
16a
17
17a
18
18a
19
19a
20
20a
22
22a
24
24a
28
28a
4
4a
5
5a
6
6a
7
7a
8
8a
9
9a
[user@Firemagic ~]$ 9p ls font/Ubuntu/24a
font
x0000.bit
x0100.bit
x0200.bit
x0300.bit
x0400.bit
x1e00.bit
x1f00.bit
x2000.bit
x2100.bit
x2200.bit
x2500.bit
xe000.bit
xef00.bit
xf000.bit
xf200.bit
xf500.bit
xf800.bit
xfb00.bit
[user@Firemagic ~]$ acme -f /mnt/font/Ubuntu/24a/font
imageinit: can't open font /mnt/font/Ubuntu/24a/font: �
acme: can't open display: �
[user@Firemagic ~]$ 

FreeBSD 10.0 default Compiler is clang

Is GCC the requirement? I will investigate more, but didn't know if anyone was aware if clang didn't support the GCC features plan9port requires (if any)

secstore hungs on password prompt...

I'm seeing random, permanent hangs under debian when using secstored. It's a stable debian kernel and system running in a vm and there's nothing really special about it. Here's the setup:

/lib/systemd/system/secstored.service:

[Unit]
Description=secstored

[Service]
User=secstored
Group=secstored
UMask=0007
Type=forking
ExecStart=/usr/local/plan9/bin/secstored -s tcp!*!5356
ExecReload=/bin/kill -s HUP $MAINPID

[Install]
WantedBy=multi-user.target

bash(indentation for readability only):

su
    useradd secstored
    mkdir /usr/local/plan9/secstore
    chown -R secstored:secstored /usr/local/plan9/secstore/
    chmod -R 770 /usr/local/plan9/secstore/
    systemctl enable secstored
    systemctl start secstored
    su - secstored
        umask 0007
        secuser luser00 #define a user's account
        exit
    exit
#testing the account
cd
touch ~/test.txt
echo foobar >> ~/test.txt
secstore -s tcp\!127.0.0.1\!5356 -p test.txt -u luser00
rm ~/test.txt
secstore -s tcp\!127.0.0.1\!5356 -G test.txt -u luser00
#you should be seeing "foobar"... but it only shows sometime... mostly, it just hangs at the prompt.

Sometimes, restarting with "systemctl restart secstored" helps. Sometimes, it hangs on the first try. Overall, very random.

Also, it's not systemd. I've used "su - secstored" and run the daemon from there and it still randomly hangs.

fontsrv: imperfect font rendering at certain sizes

On OS X, some vector fonts are not rendered correctly at certain sizes. For example, this is 14p Lucida Grande with antialising, look at 'g', 'j', and 'y', but especially 'g':

LG14anr

This is on a retina display, it has the same problem but in real life it's much less visible:

LG14ar

The 15p Lucida Grande does not have this problem. Non retina:

LG15anr

Retina:

LG15ar

This problem is not specific to Lucida Grande, in fact most fonts have some problem at some sizes. Unfortunately I couldn't find any Lucida font that rendered correctly at 14p or 13p, and 15p is too big for me. Some fonts are rendered worse than Lucida Grande though. This is Lucida Grande Light at 14p with antialising:

LGL14anr

And here is Lucida Grande Mono at 14p with antialising. Note the cut 'j':

LGM14anr

Some other fonts do work well at 14p. This is Anonymous Pro with antialising at 14p:

AP14anr

The 'g' is not cropped, though if you look in the tag you will see it touches the tag border.

If someone has an X11 server, it would be interesting to compare the results of the same fonts there too (different backend renderer).

wrong window size on start

when some p9p app like 9term, acme or sam is started under some window manager that changes its size, like the tilling window manager dwm, it does not detect that it's size has been changed and thus do not repaint itself. Because of that, the window seems to think it has a different size than it actually has. It becomes more obvious starting sam under dwm, because it's colors are not white. See example attached. When the user does anything that induces a repaint on the window, like a resize or changing to another tag and back, the problem is solved.

To reproduce: start dwm, and start sam.
Tested with plan9port-20160122 under OpenBSD 5.9 and dwm 6.1, but also reported to me by Linux users using dwm and other window managers that change the window size to their will. For example, window maker allows you to set that a certain program should be started maximized. If you do so to some p9p program, the bug reported here will happen.

Never saw this bug happen to any other program under dwm nor under any other window manager.

2016-03-31-114657_1917x1079_scrot

acme - scrolling not working as expected

Acme's scroll doesn't seem to be working as expected, and unfortunately, I can't pinpoint the issue as it's someone intermittent.

Normally, when I point to a line in the scroll bar and button-3 click, that line goes to the top of the screen. When I button-1 click a line in the scroll bar area, acme puts the top line there. The effect of this is toggling between buttons 1 and 2 will move the line the mouse cursor is on to the top of the window and back, over and over.

However, lately, there are times when button 1 will actually put the top line of the window one line below where the mouse is pointing instead. Then button 2 will put the new line it is pointing at at the top, and button 1 will again put that new line one line down, making the line above that one the new top of the page. In this way, you end up losing your place in the file one line at a time. It's a bit difficult to explain, so hopefully this makes sense.

I realize this isn't a very good bug report as I can't really pinpoint the issue. I'm hoping to at least see if anyone else is experiencing this. Window size seems to be a factor, and possibly having recently resized the window may be a factor as well. Additionally, it seems to be more of an issue when trying to scroll a large amount of lines, and less of an issue when only scrolling a few lines.

My first thought is it may be related to my MacBook Pro's retina display - that maybe the pixel count is off, so the further down the file you go, the more "off" the scrolling becomes. This is strictly a theory, as I've never had the scrolling be off by more than one line at a time. Perhaps I don't have a large enough window to test beyond that.

Edit: The issue seems to work the other way (button 3 causing the issue, so the off by one scrolling goes in the other direction) as well.

acme: crash in threadqunlock

[jacekm@jacekm-mbp cores]$ lldb -c core.33535 /src/9fans.net/plan9port/bin/acme
(lldb) target create "/src/9fans.net/plan9port/bin/acme" --core "core.33535"
warning: (x86_64) /cores/core.33535 load command 121 LC_SEGMENT_64 has a fileoff + filesize (0x20417000) that extends beyond the end of the file (0x20416000), the segment will be truncated to match
warning: (x86_64) /cores/core.33535 load command 122 LC_SEGMENT_64 has a fileoff (0x20417000) that extends beyond the end of the file (0x20416000), ignoring this section
Core file '/cores/core.33535' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff89260286:  jae    0x7fff89260290            ; __pthread_kill + 20
   0x7fff89260288:  movq   %rax, %rdi
   0x7fff8926028b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260290:  retq
  thread #2: tid = 0x0001, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #3: tid = 0x0002, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #4: tid = 0x0003, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #5: tid = 0x0004, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #6: tid = 0x0005, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #7: tid = 0x0006, 0x00007fff89261682 libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89261682 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read + 10:
-> 0x7fff89261682:  jae    0x7fff8926168c            ; read + 20
   0x7fff89261684:  movq   %rax, %rdi
   0x7fff89261687:  jmp    0x7fff8925bc78            ; cerror
   0x7fff8926168c:  retq
  thread #8: tid = 0x0007, 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff89260136 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait + 10:
-> 0x7fff89260136:  jae    0x7fff89260140            ; __psynch_cvwait + 20
   0x7fff89260138:  movq   %rax, %rdi
   0x7fff8926013b:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260140:  retq
  thread #9: tid = 0x0008, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #10: tid = 0x0009, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
  thread #11: tid = 0x000a, 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8926091a libsystem_kernel.dylib`__wait4_nocancel + 10
libsystem_kernel.dylib`__wait4_nocancel + 10:
-> 0x7fff8926091a:  jae    0x7fff89260924            ; __wait4_nocancel + 20
   0x7fff8926091c:  movq   %rax, %rdi
   0x7fff8926091f:  jmp    0x7fff8925bc53            ; cerror_nocancel
   0x7fff89260924:  retq
(lldb) bt
* thread #1: tid = 0x0000, 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff89260286 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff92ede9f9 libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff95a5a9b3 libsystem_c.dylib`abort + 129
    frame #3: 0x00000001032d0411 acme`threadqunlock(l=<unavailable>, pc=<unavailable>) + 289 at thread.c:543
    frame #4: 0x00000001032d8a03 acme`qunlock(l=0x00007f921a011400) + 51 at qlock.c:78
    frame #5: 0x00000001032b8886 acme`winunlock(w=0x00007f921a011400) + 86 at wind.c:287
    frame #6: 0x00000001032bb688 acme`xfidwrite(x=<unavailable>) + 1496 at xfid.c:617
    frame #7: 0x00000001032b9b91 acme`xfidctl(arg=0x00007f92194189e0) + 65 at xfid.c:51
    frame #8: 0x00000001032d0dea acme`threadstart(y=<unavailable>, x=<unavailable>) + 26 at thread.c:96
(lldb)

Can have spaces in file or directory name

There is no way to select a directory that has a space in its name, e.g. "MY DIR". Same for files with spaces in them. This is the single biggest reason I don't use acme all of the time.

rio: window border size issue

When using notably virtualbox on linux/x86_64; rio's window edge are "maximized" using plan9port from Jan 22, 2016. A screenshot is attached below; other windows that were open prior to virtualbox are reachable by ctrl-tab; and virtual screen selection is no longer available.

img_6547

cmd/acme: Edit X/.../ broken

Acme's implementation of the X sam looping construct crashes with error:

qunlock pc=0x1079c6b30 owner=0 self=108124000 oops

How to reproduce?

  1. Execute 'New foo'.
  2. Execute 'Edit X/foo/ >wc'.

9c: some binaries produce segmentation faults when compiled for ARMv7 with GCC on Linux

After running the INSTALL command on a machine with ARMv7-A architecture, GCC, and Linux, some of resulting binaries compiled via 9c (such as acme and 9pserve) terminated with segmentation faults. However, other binaries can run without issue. (e.g. It was possible to spot-edit in the '-marm' GCC optimization flag in 9c with sam -d and re-run the INSTALL command to get everything compiled and running without segmentation faults.)

I believe the segmentation faults have something to do with GCC defaulting to the "Thumb" instruction set on relevant ARM chips, but I could use some guidance on how to best debug and diagnose further.

An incidental fix is to add the -marm GCC optimization flag to cflags in the case of ARMv7-A chips in order to utilize the ARM instruction set instead of the Thumb instruction set. Would that be too specific of a change to 9c and would it require a more detailed explanation as to why it works (and why the -mthumb GCC default does not)?

The machine I can consistently reproduce all of this on features a Rockchip RK3288 (ARM Cortex A-17). I have a few other machines with ARMv7-A or ARMv8-A I could try reproducing on too, if that helps.

tag releases

Previously it was possible to download tarballs from google code these tarballs a slightly out of date nowadays, maybe it would be a good idea to use git-tag(1) to tag releases? When doing so GitHub automatically creates source tarballs for those git tags. This would make packaging plan9port easier.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.