From owner-freebsd-ports@freebsd.org Wed Apr 14 19:12:38 2021 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CDBA5E52B0; Wed, 14 Apr 2021 19:12:38 +0000 (UTC) (envelope-from valery@vslash.com) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FLBts0yfzz3sfp; Wed, 14 Apr 2021 19:12:36 +0000 (UTC) (envelope-from valery@vslash.com) X-Originating-IP: 88.126.50.171 Received: from dell.vslash.com (unknown [88.126.50.171]) (Authenticated sender: valery@vslash.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 576412000A; Wed, 14 Apr 2021 19:12:34 +0000 (UTC) Subject: Re: ssh_dispatch_run_fatal on Rpi4 building www/firefox To: bob prohaska , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org References: <20210414154943.GA48835@www.zefox.net> From: Valery Seys Message-ID: Date: Wed, 14 Apr 2021 21:12:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20210414154943.GA48835@www.zefox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FLBts0yfzz3sfp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of valery@vslash.com designates 217.70.183.200 as permitted sender) smtp.mailfrom=valery@vslash.com X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28]; RWL_MAILSPIKE_GOOD(0.00)[217.70.183.200:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RECEIVED_SPAMHAUS_PBL(0.00)[88.126.50.171:received]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.70.183.200:from]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.200:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[vslash.com]; SPAMHAUS_ZRD(0.00)[217.70.183.200:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-ports] X-Mailman-Approved-At: Thu, 15 Apr 2021 15:40:28 +0000 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 19:12:38 -0000 On 14/04/2021 15:49, bob prohaska wrote: > While attempting to compile www/firefox on an RPi4 running -current > the make process stopped with > > Bad packet length 3554809687. > ssh_dispatch_run_fatal: Connection to 192.168.1.11 port 22: Connection corrupted > > on the controlling terminal. > > After updating to 14.0-CURRENT FreeBSD 14.0-CURRENT #15 main-8cca7b7f2: > Tue Apr 13 17:46:39 PDT 2021 > > the error promptly recurred if make was restarted without cleaning. > > As an experiment, I've restarted the make process via a serial connection > and it didn't immediately reproduce the error. In all cases the make > command is > > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 DISABLE_VULNERABILITIES=yes > make.log > > and is run in the background. The same make command successfully compiled > www/chromium via ssh, so I don't think the culprit's the command line. > > I rather doubt this is a www/firefox problem, but include freebsd-ports > in hopes somebody might recognize the error. > > Make generates a torrent of warnings using the serial connection, such as: > > #if IN_HEADER(__GTK_ITEM_FACTORY_H__) > ^ > ./gtkalias.h:10:19: note: expanded from macro 'IN_HEADER' > #define IN_HEADER defined > ^ > ./gtkalias.h:5366:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] > #if IN_HEADER(__GTK_LABEL_H__) > ^ > ./gtkalias.h:10:19: note: expanded from macro 'IN_HEADER' > #define IN_HEADER defined > ^ > but seems to keep running via the serial connection. Top reports that > cc is in state TTYOUT, with WCPU no higher than a few percent, running > only one thread. > > Thanks for reading, and any ideas. > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Hi Bob, so you compile rpi'side, perhaps could you start sshd with '-E ' in order to get more infos. On the RPI, as root: 1) echo 'sshd_flags="-E /var/log/sshd_debug.log"' >> /etc/rc.conf 2) touch /var/log/sshd_debug.log 3) service sshd restart (if you already have sshd flags in rc.conf, plz edit instead of the echoing as above ...) Then restart your ssh session, and see what happens in the log, Ps : firefox need a huge amount of memory to compile, according to the number of compiling instances (eg cpu threads) you have, it could easily reaches >4G, so your trouble could come from this (sshd cannot be swapped ...), in this case, try to lowered the number of threads make will use, through one of these options: DISABLE_MAKE_JOBS: Set to disable the multiple jobs feature. User settable. MAKE_JOBS_NUMBER: Override the number of make jobs to be used. User settable. MAKE_JOBS_NUMBER_LIMIT: Set a limit for maximum number of make jobs allowed to be used. Get your number of cpu thread: sysctl -n kern.smp.cpus hope it helps, v/