I built a new system, did a sysupdate and started to setup remote mail This seems to happen on Reply all and it locks up the system.I have to close out Mail in acme Mail 962: suicide: invalid address 0xc008d/794680 in sys call pc=0x149e4 Mail 962: suicide: sys: bad address in syscall pc=0x000149e4
this can happen with any program that you override its binary while it is running. the text/data is demand paged, which means that under memory pressure, the kernel will discard the pages and on demand read it back from the file again. just reboot after a mk install, or use mk safeinstall (which renames the file before copying avoiding the override in place). btw, ori's new filesystem might have a experimental feature trying to make snapshots of the while when they'r opend with OEXEC flag avoiding this issue. -- cinap
[-- Attachment #1: Type: text/plain, Size: 282 bytes --] This is extremely hard to troubleshoot. I tried both mk install and mk safeinstall, rebooted twice and the problem still persists. Its unusable. I'm not familiar enough with the command line version to debug further. I also tried to make sure upas/fs was not running as well. [-- Attachment #2: Type: message/rfc822, Size: 3499 bytes --] From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] rewrite gateway Date: Fri, 28 Jan 2022 20:07:12 +0100 Message-ID: <5489EE48FB95006A7BB9588005F54AC9@felloff.net> this can happen with any program that you override its binary while it is running. the text/data is demand paged, which means that under memory pressure, the kernel will discard the pages and on demand read it back from the file again. just reboot after a mk install, or use mk safeinstall (which renames the file before copying avoiding the override in place). btw, ori's new filesystem might have a experimental feature trying to make snapshots of the while when they'r opend with OEXEC flag avoiding this issue. -- cinap
Quoth thinktankworkspaces@gmail.com:
> This is extremely hard to troubleshoot. I tried both mk install and mk safeinstall,
> rebooted twice and the problem still persists.
>
> Its unusable. I'm not familiar enough with the command line version to debug further.
>
> I also tried to make sure upas/fs was not running as well.
>
Can you reproduce it after a reboot?
And can you get a stack trace? (attach to the broken
binary with acid, and run 'lstk()')
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --] Okay I'm not sure how to run this. I recall reading somewhere in some pdf that you run acid against the proc id. So when it crashed the id was 1579 I can try doing this a different way. Please let me know but here are the results. Mail 1579: suicide: invalid address 0xc554d/816376 in sys call pc=0x149e4 Mail 1579: suicide: sys: bad address in syscall pc=0x000149e4 cpu% acid 1579 /proc/1579/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: stk() pwrite()+0x7 /sys/src/libc/9syscall/pwrite.s:5 write(fd=0xffffffff,buf=0xc554d,n=0xc74f8)+0x2f /sys/src/libc/9sys/write.c:7 _iowrite(arg=0xbcdd4)+0x2f /sys/src/libthread/iowrite.c:16 xioproc(a=0x60000)+0x1dc /sys/src/libthread/ioproc.c:66 launcher386(arg=0x60000,f=0x16005)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 acid: lstk() pwrite()+0x7 /sys/src/libc/9syscall/pwrite.s:5 write(fd=0xffffffff,buf=0xc554d,n=0xc74f8)+0x2f /sys/src/libc/9sys/write.c:7 _iowrite(arg=0xbcdd4)+0x2f /sys/src/libthread/iowrite.c:16 xioproc(a=0x60000)+0x1dc /sys/src/libthread/ioproc.c:66 c=0x60000 io=0x27c00 r=0xbcdd0 launcher386(arg=0x60000,f=0x16005)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 acid: cpu% [-- Attachment #2: Type: message/rfc822, Size: 3886 bytes --] From: ori@eigenstate.org To: 9front@9front.org Subject: Re: [9front] rewrite gateway Date: Fri, 28 Jan 2022 16:22:35 -0500 Message-ID: <06AE2F928343ABD034E665D4E7C8FDE1@eigenstate.org> Quoth thinktankworkspaces@gmail.com: > This is extremely hard to troubleshoot. I tried both mk install and mk safeinstall, > rebooted twice and the problem still persists. > > Its unusable. I'm not familiar enough with the command line version to debug further. > > I also tried to make sure upas/fs was not running as well. > Can you reproduce it after a reboot? And can you get a stack trace? (attach to the broken binary with acid, and run 'lstk()')
you didn't say if you rebooted
On 1/29/22, thinktankworkspaces@gmail.com <thinktankworkspaces@gmail.com> wrote:
> Okay I'm not sure how to run this. I recall reading somewhere in some pdf
> that you run acid
> against the proc id. So when it crashed the id was 1579
>
> I can try doing this a different way. Please let me know but here are the
> results.
>
>
> Mail 1579: suicide: invalid address 0xc554d/816376 in sys call pc=0x149e4
> Mail 1579: suicide: sys: bad address in syscall pc=0x000149e4
>
> cpu% acid 1579
> /proc/1579/text:386 plan 9 executable
> /sys/lib/acid/port
> /sys/lib/acid/386
> acid: stk()
> pwrite()+0x7 /sys/src/libc/9syscall/pwrite.s:5
> write(fd=0xffffffff,buf=0xc554d,n=0xc74f8)+0x2f
> /sys/src/libc/9sys/write.c:7
> _iowrite(arg=0xbcdd4)+0x2f /sys/src/libthread/iowrite.c:16
> xioproc(a=0x60000)+0x1dc /sys/src/libthread/ioproc.c:66
> launcher386(arg=0x60000,f=0x16005)+0x10 /sys/src/libthread/386.c:10
> 0xfefefefe ?file?:0
> acid: lstk()
> pwrite()+0x7 /sys/src/libc/9syscall/pwrite.s:5
> write(fd=0xffffffff,buf=0xc554d,n=0xc74f8)+0x2f
> /sys/src/libc/9sys/write.c:7
> _iowrite(arg=0xbcdd4)+0x2f /sys/src/libthread/iowrite.c:16
> xioproc(a=0x60000)+0x1dc /sys/src/libthread/ioproc.c:66
> c=0x60000
> io=0x27c00
> r=0xbcdd0
> launcher386(arg=0x60000,f=0x16005)+0x10 /sys/src/libthread/386.c:10
> 0xfefefefe ?file?:0
> acid: cpu%
>
it looks to me like the arguments of that ioproc are corrupted. i'v taken a look at acme mail, and iowrite is only used as a callback for a Bio buffer (procwr), which should have a maximum buffer capacity of 8K + UTFman+1, so having ~800k write size should be impossible. also note how the file descriptor is -1? very odd. you can maybe put a debug print in /sys/src/cmd/upas/Mail/win.c:^procwr i'm not acme user, lemme see if i can reproduce it on a 386 build. -- cinap
ok, just ran it in vmx on a 386 kernel and no issues. i'v put you the binary that i have here: https://felloff.net/usr/cinap_lenrek/Mail term% sha1sum /acme/bin/386/Mail 792456c61493749bcd8d82cc02e167b03cbe6647 /acme/bin/386/Mail you can download and bind it on /acme/bin/386/Mail to see if it has the same issues. -- cinap
found it. i could reproduce it on 386 when replying to a message. the issue was a classical double-free in msgshow(), calling Bterm() twite on wfd: 251c3cfd610abd169676852d301a2aa1267c0e57 acne/Mail: fix double-free (Bterm() in mesgshow()) Hash: 251c3cfd610abd169676852d301a2aa1267c0e57 Date: Sat Jan 29 21:50:03 CET 2022 Author: cinap_lenrek <cinap_lenrek@felloff.net> Message: acne/Mail: fix double-free (Bterm() in mesgshow()) --- .git/fs/object/2833aecc681aec9928c525fc2d8d023dbfe225bc/tree/sys/src/cmd/upas/Mail/comp.c +++ .git/fs/object/251c3cfd610abd169676852d301a2aa1267c0e57/tree/sys/src/cmd/upas/Mail/comp.c diff -u .git/fs/object/2833aecc681aec9928c525fc2d8d023dbfe225bc/tree/sys/src/cmd/upas/Mail/comp.c .git/fs/object/251c3cfd610abd169676852d301a2aa1267c0e57/tree/sys/src/cmd/upas/Mail/comp.c @@ -283,7 +283,6 @@ break; Bterm(rfd); } - Bterm(wfd); } Bterm(wfd); fprint(c->addr, "$"); -- cinap
Quoth cinap_lenrek@felloff.net:
> found it. i could reproduce it on 386 when replying to a message.
>
> the issue was a classical double-free in msgshow(), calling
> Bterm() twite on wfd:
>
> 251c3cfd610abd169676852d301a2aa1267c0e57 acne/Mail: fix double-free (Bterm() in mesgshow())
> Hash: 251c3cfd610abd169676852d301a2aa1267c0e57
> Date: Sat Jan 29 21:50:03 CET 2022
> Author: cinap_lenrek <cinap_lenrek@felloff.net>
> Message: acne/Mail: fix double-free (Bterm() in mesgshow())
>
> --- .git/fs/object/2833aecc681aec9928c525fc2d8d023dbfe225bc/tree/sys/src/cmd/upas/Mail/comp.c
> +++ .git/fs/object/251c3cfd610abd169676852d301a2aa1267c0e57/tree/sys/src/cmd/upas/Mail/comp.c
> diff -u .git/fs/object/2833aecc681aec9928c525fc2d8d023dbfe225bc/tree/sys/src/cmd/upas/Mail/comp.c .git/fs/object/251c3cfd610abd169676852d301a2aa1267c0e57/tree/sys/src/cmd/upas/Mail/comp.c
> @@ -283,7 +283,6 @@
> break;
> Bterm(rfd);
> }
> - Bterm(wfd);
> }
> Bterm(wfd);
> fprint(c->addr, "$");
>
> --
> cinap
I really appreciate this. I feel retarded trying to debug this. If only I can spend the day
annoyingly looking over someone else's shoulders, as they debug navigate or just generally
use this OS.
I ran another sysupdate, mk install and rebooted. Looks like its working. Thanks again!
Much appreciation.
Quoth cinap_lenrek@felloff.net:
> it looks to me like the arguments of that ioproc are corrupted.
>
> i'v taken a look at acme mail, and iowrite is only used
> as a callback for a Bio buffer (procwr), which should have
> a maximum buffer capacity of 8K + UTFman+1, so having
> ~800k write size should be impossible.
>
> also note how the file descriptor is -1?
>
> very odd.
>
> you can maybe put a debug print in /sys/src/cmd/upas/Mail/win.c:^procwr
>
> i'm not acme user, lemme see if i can reproduce it on a 386 build.
>
> --
> cinap
Could you give an example of how to use mail command line. The manpage still confuses me.
When I select the number of the message 3: r
to reply it changes the color of the sreen and throws me into marshal mode. Ctrl-D doesn't
exctly work for me i'm using an Apple Keyboard so it seems fn+ Delete breaks me out.
After which I"m not sure what command to run to send mail. It appears easy to delete a message
but replying proves confusing. y key gives me a command error. So I'm obviously doing
something wrong. Also not sure of the args to use. Seems acme Mail is the lazy way that I
rely on at the moment.
> to reply it changes the color of the screen ...
thats called hold mode. its a feature of rio the window
system. you toggle it by pressing escape key.
hold mode lets the user edit multi-line text in a window
while the program reading the input is waiting. once you
stop hold mode (by pressing escape), the program reading
input will get all the text.
in normal mode, when you press enter the program gets
the line, and editing the text in the window is editing
history (what has already been read by the program).
--
cinap
Quoth thinktankworkspaces@gmail.com:
> Ctrl-D doesn't
> exctly work for me i'm using an Apple Keyboard so it seems fn+ Delete breaks me out.
ctrl+d to end the file, escape to exit hold mode.
delete kills the current program, like ctrl+c on
unix.
asdf .