9fans / plan9port Goto Github PK
View Code? Open in Web Editor NEWPlan 9 from User Space
Home Page: https://9fans.github.io/plan9port/
License: Other
Plan 9 from User Space
Home Page: https://9fans.github.io/plan9port/
License: Other
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.
Steps to reproduce under Yosemite (Cocoa retina build):
The cursor alternates between the default system pointer (black arrow) and the appropriate sam cursor.
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
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.
How to reproduce:
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).
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.
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
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.
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?
Plan9 xd(1) supports -R
which is like -c
but rune-wise instead of char-wise.
Merged files can be found at
http://chneukirchen.org/tmp/xd.c
and
http://chneukirchen.org/tmp/xd.1
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.
I've tried installing plan9port on void linux (musl version) to find it fails. Paul Onyschuk posted some patches at https://groups.google.com/forum/#!topic/plan9port-dev/trEfAGRHPfA . I wonder if these could be incorporated? His post has no replies and there are no other issues about this open or closed here, so I'm not sure what's the status on this.
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:
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.
rand(3) describes frand(), but when i tried to compile, i get an undefined reference to p9frand.
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.
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
[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)
Steps to reproduce:
acme -al
Expected:
Result:
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.
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.
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.
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
src/libmach/symstabs.c:316,317 the local struct ss is used uninitialized.
Acme's implementation of the X sam looping construct crashes with error:
qunlock pc=0x1079c6b30 owner=0 self=108124000 oops
How to reproduce?
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.
The link 'browse' and 'hgweb' points to dead locations.
can plan9port be ported to a platform with out pthreads?
(minix3)
what I am seeking is to get acme ported to minix3.
any pointers?
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':
This is on a retina display, it has the same problem but in real life it's much less visible:
The 15p Lucida Grande does not have this problem. Non retina:
Retina:
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:
And here is Lucida Grande Mono at 14p with antialising. Note the cut 'j':
Some other fonts do work well at 14p. This is Anonymous Pro with antialising at 14p:
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).
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.
>>> 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
[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)
Mousectl actually contains Mouse m; not Mouse;
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)
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.
Acme's window will turn all-gray and hang forever if the user presses 2 keys and the touchpad in the following order:
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.
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)
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.
For example, http://swtch.com/plan9port/man/man1/install.html gives a 404.
this would make 9c much more 9-like.
Kdel is missing from keyboard.h.
http://plan9.bell-labs.com/sources/plan9/sys/include/keyboard.h
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);
@
Line 669 in 3f1c876
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.
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)
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 ~]$
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.
(Linux)
If Enter is pressed, the pixels reappear:
also, if Backspace is pressed when cursor is here:
returns the pixels for the moment:
pressing anything (Space etc.) removes them.
Other archival utilities in unix tend to have this as an option:
-X Do not cross mount points in the file system.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.