[9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

Hardware: IBM Thinkpad T460S
OS: FreeBSD 13.2-STABLE
CPU: Intel i7-6600U (4) @ 2.800GHz
GPU: Skylake GT2 [HD Graphics 520]
Memory: 2445MiB / 20284MiB
Shell: BASH/FISH/ZSH

Version: 9Front drawterm current
Port: Not using port version of drawterm

Ran git command, copied over drawterm.
Ran CONF=freebsd make
made file
ran drawterm command specifc to SDF server
got drawterm connect, put in password
connects

drawterm message:
cpu failed to chdir to '/usr/home/myuser/drawterm'
exits
shell (any of the three) [SIGSEGV]
Job 1, './drawterm -h 205.166.XX.XXX -a' terminated by signal SIGSEGV 
(Address boundary error)
echo exit status on $? is 139
tail on messages/dmesg (same):
kernel: pid 78299 (drawterm), jid 0, uid 1002: exited on signal 11

Similar configuration works fine on debian, so I'm not able to produce 
the error there.  Permissions for folders are similar.  Opened up the 
drawterm folder with a recursive perm of 777, 
even sudo'd the command, same error.

no dumps I coud find, so no help there.

Let me know if anyone has any advice on how to debug/troubleshoot.

Really appreciate your time, beat the shit out of the internet trying to 
find an answer on the lists/forums/etc.

/usr/games/catclock misses me.

Cheers,
DMad





dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[hiro]

> no dumps I coud find, so no help there.

read the freebsd man pages to find out how to make a dump

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Amavect]

On Fri, Sep 22, 2023 at 2:21 PM Dmad <dmadhatr@sdf.org> wrote:
> Let me know if anyone has any advice on how to debug/troubleshoot.
>
> Really appreciate your time, beat the shit out of the internet trying to
> find an answer on the lists/forums/etc.
Do you know how to get a backtrace with gdb or any other debugger?
For gdb, just pass the executable filename, type r to run.
Trigger the crash, and type bt for a backtrace.

Additionally, you can recompile with "-O0 -ggdb" in the CFLAGS.
If that changes the behavior, that's a hint as to what's wrong.

Thanks,
Amavect

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Fri, 22 Sep 2023, hiro wrote:

> Date: Fri, 22 Sep 2023 21:55:24 +0200
> From: hiro <23hiro@gmail.com>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
>> no dumps I coud find, so no help there.
>
> read the freebsd man pages to find out how to make a dump
>

Thanks Hiro, started reading through their sysctl and dump tool mans/docs.
Found one (super small) script error in the drawterm make files, but will 
send that to 
the project.

Cheers

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Fri, 22 Sep 2023, Amavect wrote:

> Date: Fri, 22 Sep 2023 20:10:29 -0500
> From: Amavect <amavect@gmail.com>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Fri, Sep 22, 2023 at 2:21?PM Dmad <dmadhatr@sdf.org> wrote:
>> Let me know if anyone has any advice on how to debug/troubleshoot.
>>
>> Really appreciate your time, beat the shit out of the internet trying to
>> find an answer on the lists/forums/etc.
> Do you know how to get a backtrace with gdb or any other debugger?
> For gdb, just pass the executable filename, type r to run.
> Trigger the crash, and type bt for a backtrace.
>
> Additionally, you can recompile with "-O0 -ggdb" in the CFLAGS.
> If that changes the behavior, that's a hint as to what's wrong.
>
> Thanks,
> Amavect
>
>

Amavect, I started reading up on using backtrace with gdb yesterday as 
well- so 
that too is solid advice - thanks.  Will continue to hunt.   Will run with 
the recompile and the CFLAGS you gave.

Apprciate it, thanks..

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sat, 23 Sep 2023, Dmad wrote:

> Date: Sat, 23 Sep 2023 13:52:04 +0000 (UTC)
> From: Dmad <dmadhatr@sdf.org>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Fri, 22 Sep 2023, Amavect wrote:
>
>>  Date: Fri, 22 Sep 2023 20:10:29 -0500
>>  From: Amavect <amavect@gmail.com>
>>  Reply-To: 9front@9front.org
>>  To: 9front@9front.org
>>  Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>
>>  On Fri, Sep 22, 2023 at 2:21?PM Dmad <dmadhatr@sdf.org> wrote:
>>>  Let me know if anyone has any advice on how to debug/troubleshoot.
>>>
>>>  Really appreciate your time, beat the shit out of the internet trying to
>>>  find an answer on the lists/forums/etc.
>>  Do you know how to get a backtrace with gdb or any other debugger?
>>  For gdb, just pass the executable filename, type r to run.
>>  Trigger the crash, and type bt for a backtrace.
>>
>>  Additionally, you can recompile with "-O0 -ggdb" in the CFLAGS.
>>  If that changes the behavior, that's a hint as to what's wrong.
>>
>>  Thanks,
>>  Amavect
>> 
>> 
>
> Amavect, I started reading up on using backtrace with gdb yesterday as well- 
> so that too is solid advice - thanks.  Will continue to hunt.   Will run with 
> the recompile and the CFLAGS you gave.
>
> Apprciate it, thanks..
>
> dmadhatr@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>
>

Ok, here is what I found:

dmadhatr@dmadhatr-freetbsd-pc ~/drawterm (front)> gdb -ex=run --args 
./drawterm -h 205.166.XX.XXX -a 205.166.XX.XXX -u glenda -r 
/home/dmadhatr/Public/
GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
 	<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./drawterm...
Starting program: /usr/home/dmadhatr/drawterm/drawterm -h 205.166.XX.XXX 
-a 205.166.XX.XXX -u glenda -r /home/dmadhatr/Public/
[New LWP 130212 of process 59751]
[New LWP 130213 of process 59751]
[New LWP 130217 of process 59751]

Thread 1 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
9		asm(	"movl   $1, %%eax\n\t"
(gdb) bt
#0  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
#1  0x000000000028dd5b in canlock (lk=0x0) at lock.c:62
#2  lock (lk=lk@entry=0x0) at lock.c:71
#3  0x0000000000226cdf in incref (r=0x0) at chan.c:57
#4  walk (cp=cp@entry=0x7fffffffdf18, names=0x800d2c780, nnames=2, 
nomount=nomount@entry=0, nerror=nerror@entry=0x7fffffffdeec) at chan.c:847
#5  0x0000000000227ed3 in namec (aname=0x800c3ce80 "./dev/label", 
aname@entry=0x800c3ce60 "./dev/label", amode=amode@entry=0, 
omode=omode@entry=0, perm=perm@entry=0) at chan.c:1273
#6  0x0000000000242e1b in _sysstat (name=0x0, name@entry=0x800c3ce60 
"./dev/label", buf=buf@entry=0x800c57050, n=n@entry=115) at sysfile.c:612
#7  0x00000000002443c4 in sysstat (name=name@entry=0x800c3ce60 
"./dev/label", buf=buf@entry=0x800c57050 "dev", n=n@entry=115) at 
sysfile.c:1099
#8  0x00000000002894b7 in dirstat (name=0x800c3ce60 "./dev/label") at 
dirstat.c:23
#9  0x00000000002481ca in file (parent=0x800c49310, 
name=name@entry=0x800d4df52 "label") at exportfs.c:284
#10 0x0000000000248cc7 in Xwalk (t=0x800d44350) at exportsrv.c:199
#11 0x0000000000247820 in exportfs (fd=fd@entry=6) at exportfs.c:99
#12 0x000000000022211e in ncpu (host=<optimized out>, cmd=<optimized out>) 
at cpu.c:239
#13 0x0000000000222901 in cpubody () at cpu.c:384
#14 0x0000000000285f3a in guimain () at x11.c:1259
#15 0x000000000022275a in cpumain (argc=0, argc@entry=9, argv=<optimized 
out>, argv@entry=0x7fffffffe5f0) at cpu.c:335
#16 0x00000000002218cc in main (argc=9, argv=0x7fffffffe5f0) at main.c:67

----- First Run with gdb and bt -----

---- Recompiling .drawterm with CFLAGS recommending and running again ----
# Recompiling with -O0 -ggdb for CONF=freebsd make
# tar'd /proc/59751 to debug folder for trouble shooting

Was not able to get a bt stack after compiling with additional CFLAGs

Same error message, drawterm unable to chdir (see first email).


dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sat, 23 Sep 2023, Dmad wrote:

> Date: Sat, 23 Sep 2023 16:04:28 +0000 (UTC)
> From: Dmad <dmadhatr@sdf.org>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Sat, 23 Sep 2023, Dmad wrote:
>
>>  Date: Sat, 23 Sep 2023 13:52:04 +0000 (UTC)
>>  From: Dmad <dmadhatr@sdf.org>
>>  Reply-To: 9front@9front.org
>>  To: 9front@9front.org
>>  Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>
>>  On Fri, 22 Sep 2023, Amavect wrote:
>>
>>>   Date: Fri, 22 Sep 2023 20:10:29 -0500
>>>   From: Amavect <amavect@gmail.com>
>>>   Reply-To: 9front@9front.org
>>>   To: 9front@9front.org
>>>   Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>>
>>>   On Fri, Sep 22, 2023 at 2:21?PM Dmad <dmadhatr@sdf.org> wrote:
>>>>   Let me know if anyone has any advice on how to debug/troubleshoot.
>>>>
>>>>   Really appreciate your time, beat the shit out of the internet trying
>>>>   to
>>>>   find an answer on the lists/forums/etc.
>>>   Do you know how to get a backtrace with gdb or any other debugger?
>>>   For gdb, just pass the executable filename, type r to run.
>>>   Trigger the crash, and type bt for a backtrace.
>>>
>>>   Additionally, you can recompile with "-O0 -ggdb" in the CFLAGS.
>>>   If that changes the behavior, that's a hint as to what's wrong.
>>>
>>>   Thanks,
>>>   Amavect
>>>
>>> 
>>
>>  Amavect, I started reading up on using backtrace with gdb yesterday as
>>  well- so that too is solid advice - thanks.  Will continue to hunt.   Will
>>  run with the recompile and the CFLAGS you gave.
>>
>>  Apprciate it, thanks..
>>
>>  dmadhatr@sdf.org
>>  SDF Public Access UNIX System - http://sdf.org
>> 
>> 
>
> Ok, here is what I found:
>
> dmadhatr@dmadhatr-freetbsd-pc ~/drawterm (front)> gdb -ex=run --args 
> ./drawterm -h 205.166.XX.XXX -a 205.166.XX.XXX -u glenda -r 
> /home/dmadhatr/Public/
> GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd13.2".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> 	 <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./drawterm...
> Starting program: /usr/home/dmadhatr/drawterm/drawterm -h 205.166.XX.XXX -a 
> 205.166.XX.XXX -u glenda -r /home/dmadhatr/Public/
> [New LWP 130212 of process 59751]
> [New LWP 130213 of process 59751]
> [New LWP 130217 of process 59751]
>
> Thread 1 received signal SIGSEGV, Segmentation fault.
> Address not mapped to object.
> 0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
> 9		asm(	"movl   $1, %%eax\n\t"
> (gdb) bt
> #0  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
> #1  0x000000000028dd5b in canlock (lk=0x0) at lock.c:62
> #2  lock (lk=lk@entry=0x0) at lock.c:71
> #3  0x0000000000226cdf in incref (r=0x0) at chan.c:57
> #4  walk (cp=cp@entry=0x7fffffffdf18, names=0x800d2c780, nnames=2, 
> nomount=nomount@entry=0, nerror=nerror@entry=0x7fffffffdeec) at chan.c:847
> #5  0x0000000000227ed3 in namec (aname=0x800c3ce80 "./dev/label", 
> aname@entry=0x800c3ce60 "./dev/label", amode=amode@entry=0, 
> omode=omode@entry=0, perm=perm@entry=0) at chan.c:1273
> #6  0x0000000000242e1b in _sysstat (name=0x0, name@entry=0x800c3ce60 
> "./dev/label", buf=buf@entry=0x800c57050, n=n@entry=115) at sysfile.c:612
> #7  0x00000000002443c4 in sysstat (name=name@entry=0x800c3ce60 "./dev/label", 
> buf=buf@entry=0x800c57050 "dev", n=n@entry=115) at sysfile.c:1099
> #8  0x00000000002894b7 in dirstat (name=0x800c3ce60 "./dev/label") at 
> dirstat.c:23
> #9  0x00000000002481ca in file (parent=0x800c49310, 
> name=name@entry=0x800d4df52 "label") at exportfs.c:284
> #10 0x0000000000248cc7 in Xwalk (t=0x800d44350) at exportsrv.c:199
> #11 0x0000000000247820 in exportfs (fd=fd@entry=6) at exportfs.c:99
> #12 0x000000000022211e in ncpu (host=<optimized out>, cmd=<optimized out>) at 
> cpu.c:239
> #13 0x0000000000222901 in cpubody () at cpu.c:384
> #14 0x0000000000285f3a in guimain () at x11.c:1259
> #15 0x000000000022275a in cpumain (argc=0, argc@entry=9, argv=<optimized 
> out> , argv@entry=0x7fffffffe5f0) at cpu.c:335
> #16 0x00000000002218cc in main (argc=9, argv=0x7fffffffe5f0) at main.c:67
>
> ----- First Run with gdb and bt -----
>
> ---- Recompiling .drawterm with CFLAGS recommending and running again ----
> #  Recompiling with -O0 -ggdb for CONF=freebsd make
> #  tar'd /proc/59751 to debug folder for trouble shooting
>
> Was not able to get a bt stack after compiling with additional CFLAGs
>
> Same error message, drawterm unable to chdir (see first email).
>
>
> dmadhatr@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>
>

 From what I've been reading on these errors, increasing kern.maxfiles in 
/etc/sysctl.conf may be a good initial fix.

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sat, 23 Sep 2023, Dmad wrote:

> Date: Sat, 23 Sep 2023 17:32:43 +0000 (UTC)
> From: Dmad <dmadhatr@sdf.org>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Sat, 23 Sep 2023, Dmad wrote:
>
>>  Date: Sat, 23 Sep 2023 16:04:28 +0000 (UTC)
>>  From: Dmad <dmadhatr@sdf.org>
>>  Reply-To: 9front@9front.org
>>  To: 9front@9front.org
>>  Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>
>>  On Sat, 23 Sep 2023, Dmad wrote:
>>
>>>   Date: Sat, 23 Sep 2023 13:52:04 +0000 (UTC)
>>>   From: Dmad <dmadhatr@sdf.org>
>>>   Reply-To: 9front@9front.org
>>>   To: 9front@9front.org
>>>   Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>>
>>>   On Fri, 22 Sep 2023, Amavect wrote:
>>>
>>>>    Date: Fri, 22 Sep 2023 20:10:29 -0500
>>>>    From: Amavect <amavect@gmail.com>
>>>>    Reply-To: 9front@9front.org
>>>>    To: 9front@9front.org
>>>>    Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>>>
>>>>    On Fri, Sep 22, 2023 at 2:21?PM Dmad <dmadhatr@sdf.org> wrote:
>>>>>    Let me know if anyone has any advice on how to debug/troubleshoot.
>>>>>
>>>>>    Really appreciate your time, beat the shit out of the internet trying
>>>>>    to
>>>>>    find an answer on the lists/forums/etc.
>>>>    Do you know how to get a backtrace with gdb or any other debugger?
>>>>    For gdb, just pass the executable filename, type r to run.
>>>>    Trigger the crash, and type bt for a backtrace.
>>>>
>>>>    Additionally, you can recompile with "-O0 -ggdb" in the CFLAGS.
>>>>    If that changes the behavior, that's a hint as to what's wrong.
>>>>
>>>>    Thanks,
>>>>    Amavect
>>>>
>>>> 
>>>
>>>   Amavect, I started reading up on using backtrace with gdb yesterday as
>>>   well- so that too is solid advice - thanks.  Will continue to hunt.
>>>   Will
>>>   run with the recompile and the CFLAGS you gave.
>>>
>>>   Apprciate it, thanks..
>>>
>>>   dmadhatr@sdf.org
>>>   SDF Public Access UNIX System - http://sdf.org
>>>
>>> 
>>
>>  Ok, here is what I found:
>>
>>  dmadhatr@dmadhatr-freetbsd-pc ~/drawterm (front)> gdb -ex=run --args
>>  ./drawterm -h 205.166.XX.XXX -a 205.166.XX.XXX -u glenda -r
>>  /home/dmadhatr/Public/
>>  GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
>>  Copyright (C) 2023 Free Software Foundation, Inc.
>>  License GPLv3+: GNU GPL version 3 or later
>>  <http://gnu.org/licenses/gpl.html>
>>  This is free software: you are free to change and redistribute it.
>>  There is NO WARRANTY, to the extent permitted by law.
>>  Type "show copying" and "show warranty" for details.
>>  This GDB was configured as "x86_64-portbld-freebsd13.2".
>>  Type "show configuration" for configuration details.
>>  For bug reporting instructions, please see:
>>  <https://www.gnu.org/software/gdb/bugs/>.
>>  Find the GDB manual and other documentation resources online at:
>>    <http://www.gnu.org/software/gdb/documentation/>.
>>
>>  For help, type "help".
>>  Type "apropos word" to search for commands related to "word"...
>>  Reading symbols from ./drawterm...
>>  Starting program: /usr/home/dmadhatr/drawterm/drawterm -h 205.166.XX.XXX
>>  -a 205.166.XX.XXX -u glenda -r /home/dmadhatr/Public/
>>  [New LWP 130212 of process 59751]
>>  [New LWP 130213 of process 59751]
>>  [New LWP 130217 of process 59751]
>>
>>  Thread 1 received signal SIGSEGV, Segmentation fault.
>>  Address not mapped to object.
>>  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
>>  9		asm(	"movl   $1, %%eax\n\t"
>>  (gdb) bt
>>  #0  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
>>  #1  0x000000000028dd5b in canlock (lk=0x0) at lock.c:62
>>  #2  lock (lk=lk@entry=0x0) at lock.c:71
>>  #3  0x0000000000226cdf in incref (r=0x0) at chan.c:57
>>  #4  walk (cp=cp@entry=0x7fffffffdf18, names=0x800d2c780, nnames=2,
>>  nomount=nomount@entry=0, nerror=nerror@entry=0x7fffffffdeec) at chan.c:847
>>  #5  0x0000000000227ed3 in namec (aname=0x800c3ce80 "./dev/label",
>>  aname@entry=0x800c3ce60 "./dev/label", amode=amode@entry=0,
>>  omode=omode@entry=0, perm=perm@entry=0) at chan.c:1273
>>  #6  0x0000000000242e1b in _sysstat (name=0x0, name@entry=0x800c3ce60
>>  "./dev/label", buf=buf@entry=0x800c57050, n=n@entry=115) at sysfile.c:612
>>  #7  0x00000000002443c4 in sysstat (name=name@entry=0x800c3ce60
>>  "./dev/label", buf=buf@entry=0x800c57050 "dev", n=n@entry=115) at
>>  sysfile.c:1099
>>  #8  0x00000000002894b7 in dirstat (name=0x800c3ce60 "./dev/label") at
>>  dirstat.c:23
>>  #9  0x00000000002481ca in file (parent=0x800c49310,
>>  name=name@entry=0x800d4df52 "label") at exportfs.c:284
>>  #10 0x0000000000248cc7 in Xwalk (t=0x800d44350) at exportsrv.c:199
>>  #11 0x0000000000247820 in exportfs (fd=fd@entry=6) at exportfs.c:99
>>  #12 0x000000000022211e in ncpu (host=<optimized out>, cmd=<optimized out>)
>>  at cpu.c:239
>>  #13 0x0000000000222901 in cpubody () at cpu.c:384
>>  #14 0x0000000000285f3a in guimain () at x11.c:1259
>>  #15 0x000000000022275a in cpumain (argc=0, argc@entry=9, argv=<optimized 
>> out>  , argv@entry=0x7fffffffe5f0) at cpu.c:335
>>  #16 0x00000000002218cc in main (argc=9, argv=0x7fffffffe5f0) at main.c:67
>>
>>  ----- First Run with gdb and bt -----
>>
>>  ---- Recompiling .drawterm with CFLAGS recommending and running again ----
>> #   Recompiling with -O0 -ggdb for CONF=freebsd make
>> #   tar'd /proc/59751 to debug folder for trouble shooting
>>
>>  Was not able to get a bt stack after compiling with additional CFLAGs
>>
>>  Same error message, drawterm unable to chdir (see first email).
>> 
>>
>>  dmadhatr@sdf.org
>>  SDF Public Access UNIX System - http://sdf.org
>> 
>> 
>
> From what I've been reading on these errors, increasing kern.maxfiles in 
> /etc/sysctl.conf may be a good initial fix.
>
> dmadhatr@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>

Changing the stack limit and proc/file sizes did not yield an additional 
correction to the initial issue.  Appears to be some type of bug in either 
.drawterm or 
some c libs and how the virtual link from /usr/home/ to /home is handled - 
do not know enough yet to intelligently 
share more here.  Got some additional data, will keep plugging away.

gdb and bt are working fine, figured out the cores - thanks again.

Cheers.


dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Sigrid Solveig Haflínudóttir]

Try to replace the entirety of your amd64/tas.c "tas" function with just "return __atomic_test_and_set(x, __ATOMIC_ACQ_REL);", as appears in arm64/tas.c
See if that helps.

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sun, 24 Sep 2023, Sigrid Solveig Hafl?nud?ttir wrote:

> Date: Sun, 24 Sep 2023 04:28:27 +0200
> From: Sigrid Solveig Hafl?nud?ttir <sigrid@ftrv.se>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> Try to replace the entirety of your amd64/tas.c "tas" function with just "return __atomic_test_and_set(x, __ATOMIC_ACQ_REL);", as appears in arm64/tas.c
> See if that helps.
>
>

Awesome, will copy that over - good idea, thank you.

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sun, 24 Sep 2023, Sigrid Solveig Hafl?nud?ttir wrote:

> Date: Sun, 24 Sep 2023 04:28:27 +0200
> From: Sigrid Solveig Hafl?nud?ttir <sigrid@ftrv.se>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> Try to replace the entirety of your amd64/tas.c "tas" function with just "return __atomic_test_and_set(x, __ATOMIC_ACQ_REL);", as appears in arm64/tas.c
> See if that helps.
>
>

Backed up tas.c
Replaced tas function with just 'return' ... from arm64 tas.c to amd84
Recompiled
./drawterm -h IP -a IP -u glenda
No crash, but no RIO just yet.
Progress!
Thanks!

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re:SOLVED [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sun, 24 Sep 2023, Dmad wrote:

> Date: Sun, 24 Sep 2023 03:11:13 +0000 (UTC)
> From: Dmad <dmadhatr@sdf.org>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Sun, 24 Sep 2023, Sigrid Solveig Hafl?nud?ttir wrote:
>
>>  Date: Sun, 24 Sep 2023 04:28:27 +0200
>>  From: Sigrid Solveig Hafl?nud?ttir <sigrid@ftrv.se>
>>  Reply-To: 9front@9front.org
>>  To: 9front@9front.org
>>  Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
>>
>>  Try to replace the entirety of your amd64/tas.c "tas" function with just
>>  "return __atomic_test_and_set(x, __ATOMIC_ACQ_REL);", as appears in
>>  arm64/tas.c
>>  See if that helps.
>> 
>> 
>
> Backed up tas.c
> Replaced tas function with just 'return' ... from arm64 tas.c to amd84
> Recompiled
> ./drawterm -h IP -a IP -u glenda
> No crash, but no RIO just yet.
> Progress!
> Thanks!
>
> dmadhatr@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>

Retarted drawterm session, removed -r option and was able to get rio 
running from 9p.sdf.org without any crash/segsdev 11 or stack issue.

Replacing the tas function for AMD64 before recompiling appears to have 
worked.

Cheers and thanks again, appreciated.

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Amavect]

On Sat, Sep 23, 2023 at 6:24 PM Dmad <dmadhatr@sdf.org> wrote:
> #3  0x0000000000226cdf in incref (r=0x0) at chan.c:57
You have a null pointer dereference.

Digging into this a bit,
kern/chan.c:847: incref(&path->ref);
ref is the first member of path, and path is not dereferenced,
so the question is where c->path is set to null.

A path of "./dev/label" results in namec()'s default case to be taken.
kern/chan.c:1222: c = up->dot;

up->dot appears to be defined in _syschdir().
We know that chdir failed, so something happened.
kern/sysfile:628:
validaddr(name, 1, 0);
c = namec(name, Atodir, 0, 0);
cclose(up->dot);
up->dot = c;

Note that the validaddr() is a no-op macro on drawterm,
but an actual function on 9front.
If that would detect a problem, then maybe drawterm should have it.
Perhaps someone else has a better idea of kernel internals,
and how they parallel to drawterm.

> Was not able to get a bt stack after compiling with additional CFLAGs
Clearly a crash didn't happen with -O0.
Were you able to login and start typing commands into drawterm?

For fun, I installed FreeBSD on Qemu and compiled drawterm.
No issues logging onto my server,
but I don't know how to trigger a chdir failure.

Thanks,
Amavect

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Sat, 23 Sep 2023, Amavect wrote:

Was able to fix the memory issue with a tas.c function replacement 
yesterday, 
however, you may have found a way to fix the cpu bug message everyone has 
been getting from the 9front drawterm build.

> Date: Sat, 23 Sep 2023 23:44:32 -0500
> From: Amavect <amavect@gmail.com>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
> On Sat, Sep 23, 2023 at 6:24?PM Dmad <dmadhatr@sdf.org> wrote:
>> #3  0x0000000000226cdf in incref (r=0x0) at chan.c:57
> You have a null pointer dereference.
>
> Digging into this a bit,
> kern/chan.c:847: incref(&path->ref);
> ref is the first member of path, and path is not dereferenced,
> so the question is where c->path is set to null.
>
> A path of "./dev/label" results in namec()'s default case to be taken.
> kern/chan.c:1222: c = up->dot;
>
> up->dot appears to be defined in _syschdir().
> We know that chdir failed, so something happened.
> kern/sysfile:628:
> validaddr(name, 1, 0);
> c = namec(name, Atodir, 0, 0);
> cclose(up->dot);
> up->dot = c;
>
> Note that the validaddr() is a no-op macro on drawterm,
> but an actual function on 9front.
> If that would detect a problem, then maybe drawterm should have it.
> Perhaps someone else has a better idea of kernel internals,
> and how they parallel to drawterm.
>
>> Was not able to get a bt stack after compiling with additional CFLAGs
> Clearly a crash didn't happen with -O0.
> Were you able to login and start typing commands into drawterm?
>
> For fun, I installed FreeBSD on Qemu and compiled drawterm.
> No issues logging onto my server,
> but I don't know how to trigger a chdir failure.
>
> Thanks,
> Amavect
>
>

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Xiao-Yong Jin]

> Thread 1 received signal SIGSEGV, Segmentation fault.
> Address not mapped to object.
> 0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
> 9 asm( "movl   $1, %%eax\n\t"
> (gdb) bt
> #0  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
> #1  0x000000000028dd5b in canlock (lk=0x0) at lock.c:62

Try this change in Make.freebsd

; grep '^PTHREAD' drawterm/Make.freebsd
PTHREAD=-pthread -DPTHREAD

I don't remember what's wrong with the tas code.

By the way, FreeBSD should by default have unlimited coredump,
from coredumpsize in /etc/login.conf. And lldb comes with the
system.

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Dmad]

On Mon, 25 Sep 2023, Xiao-Yong Jin wrote:

Will do and thank you!


> Date: Mon, 25 Sep 2023 08:54:03 -0500
> From: Xiao-Yong Jin <meta.jxy@gmail.com>
> Reply-To: 9front@9front.org
> To: 9front@9front.org
> Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV
> 
>
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> Address not mapped to object.
>> 0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
>> 9 asm( "movl   $1, %%eax\n\t"
>> (gdb) bt
>> #0  0x0000000000294488 in tas (x=x@entry=0x0) at tas.c:9
>> #1  0x000000000028dd5b in canlock (lk=0x0) at lock.c:62
>
> Try this change in Make.freebsd
>
> ; grep '^PTHREAD' drawterm/Make.freebsd
> PTHREAD=-pthread -DPTHREAD
>
> I don't remember what's wrong with the tas code.
>
> By the way, FreeBSD should by default have unlimited coredump,
> from coredumpsize in /etc/login.conf. And lldb comes with the
> system.
>

dmadhatr@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV

[Amavect]

On Mon, Sep 25, 2023 at 11:54 PM Dmad <dmadhatr@sdf.org> wrote:
> Was able to fix the memory issue with a tas.c function replacement
> yesterday,
> however, you may have found a way to fix the cpu bug message everyone has
> been getting from the 9front drawterm build.
More people than just you have been getting that error message?
I'll probably apply to sdf to get my hands on this...

Thanks,
Amavect