From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2632 invoked from network); 24 Sep 2023 01:44:35 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Sep 2023 01:44:35 -0000 Received: from mx.sdf.org ([205.166.94.24]) by 9front; Sat Sep 23 21:39:22 -0400 2023 Received: from sdf.org (IDENT:dmadhatr@sverige.sdf.org [205.166.94.6]) by mx.sdf.org (8.16.1/8.14.5) with ESMTPS id 38O1dGax006780 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO) for <9front@9front.org>; Sun, 24 Sep 2023 01:39:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sdf.org; s=sdf.org; t=1695519559; bh=3+rpVfyHCA1vGAsZsLQJzXVhO/45waZkIdG51sPjeLg=; h=Date:From:To:Subject:In-Reply-To:References; b=1WJ1tut9nCOWZ848jhA6+zfhoW2dMoByMzB+3s/FgGLk2ikg+mdMx5fngcO3ec5FY I38Nt0qQa+8VZmmKvC+WoSQneK2YgjcOlngfH5zVzMp/3GKUzJK4JyXeEjglZlVKOW vEIeT0leZ8Qx2vtbJUfn2SXIzyzyeM8+fXEmOCMc= Received: from localhost (dmadhatr@localhost) by sdf.org (8.16.1/8.12.8/Submit) with ESMTP id 38O1dFrH029230 for <9front@9front.org>; Sun, 24 Sep 2023 01:39:15 GMT Date: Sun, 24 Sep 2023 01:39:15 +0000 (UTC) From: Dmad To: 9front@9front.org In-Reply-To: <931efd84-9713-5263-02ca-8dc5a93e8304@sdf.org> Message-ID: <921e22d1-a126-4009-ac17-c1c730769b3e@sdf.org> References: <8ea3b9d6-c797-179b-cf09-860ebbb4ade5@sdf.org> <5bd1f3ec-58ee-9618-fbfe-caefe906e1f4@sdf.org> <0e548cd8-4376-de24-6a78-000f0d98beb0@sdf.org> <931efd84-9713-5263-02ca-8dc5a93e8304@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic hypervisor package SQL self-signing realtime realtime metadata Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV Reply-To: 9front@9front.org Precedence: bulk On Sat, 23 Sep 2023, Dmad wrote: > Date: Sat, 23 Sep 2023 17:32:43 +0000 (UTC) > From: Dmad > 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 >> 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 >>> 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 >>>> 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 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 >> >> 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: >> . >> Find the GDB manual and other documentation resources online at: >> . >> >> 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=, cmd=) >> 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=> 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