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

[Dmad <dmadhatr@sdf.org>]

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