Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311
[This report just shows some material for the
sendmail SIGSEGV's, based on truss output.]
I've returned to using the modern jemalloc because
it seems to show problems more, after having
caught the earlier reported dhclient example under
the older jemalloc context. (Again: jemalloc may
be exposing a problem elsewhere.)
I had truss monitor sendmail, including following
child processes. A child process start and end
normally looks like:
963: 3092.707439595 0.33895 sigprocmask(SIG_SETMASK,{ SIGCHLD },0x0) = 0
(0x0)
2432: 3092.708024959 0.0
963: 3092.708136462 0.000470115 fork() = 2432 (0x980)
2432: 3092.708441039 0.33319 thr_self(0x5012) = 0 (0x0)
. . .
2432: 3092.717283761 0.36008 sigaction(SIGQUIT,{ SIG_IGN SA_RESTART ss_t
},{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0)
2432: 3092.717544288 0.34352 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
2432: 3092.717799894 0.35768 close(0) = 0 (0x0)
2432: 3092.718174733 0.000103726 openat(AT_FDCWD,"/dev/null",O_RDONLY,00) = 0
(0x0)
2432: 3092.718480437 0.52091 openat(AT_FDCWD,"/dev/null",O_WRONLY,00) = 4
(0x4)
2432: 3092.718778028 0.37856 dup2(4,1) = 1 (0x1)
2432: 3092.719003051 0.34255 dup2(4,2) = 2 (0x2)
2432: 3092.719225122 0.33655 close(4) = 0 (0x0)
2432: 3092.719437735 0.47626 fstat(0,{ mode=crw-rw-rw-
,inode=22,size=0,blksize=4096 }) = 0 (0x0)
2432: 3092.719679274 0.37400 fstat(1,{ mode=crw-rw-rw-
,inode=22,size=0,blksize=4096 }) = 0 (0x0)
2432: 3092.719908859 0.35816 fstat(2,{ mode=crw-rw-rw-
,inode=22,size=0,blksize=4096 }) = 0 (0x0)
2432: 3092.720138299 0.33727 clock_gettime(13,{ 1588570204.0 }) =
0 (0x0)
2432: 3092.720658945 0.35360 getpid() = 2432 (0x980)
2432: 3092.720931594 0.48730
__sysctl("kern.proc.args.2432",4,0x0,0x0,0x508ae000,49) = 0 (0x0)
2432: 3092.721572338 0.62318
open(".",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,00) = 4 (0x4)
2432: 3092.721962132 0.37808 fcntl(4,F_ISUNIONSTACK,0x0) = 0 (0x0)
2432: 3092.722323792 0.98613
getdirentries(4,"\0\0\0\0\0\t\M-I\M^Q\0\0\0\0\0\0"...,4096,{ 0x0 }) = 144 (0x90)
2432: 3092.722944875 0.36944 getdirentries(4,0x50859000,4096,{ 0x200 }) =
0 (0x0)
2432: 3092.723294461 0.45250 close(4) = 0 (0x0)
2432: 3092.723576400 0.41144 clock_gettime(13,{ 1588570204.0 }) =
0 (0x0)
2432: 3092.723828718 0.37928 setitimer(0,{ 0.00, 0.00 },0x0) = 0
(0x0)
2432: 3092.724092245 0.35815 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ }) = 0
(0x0)
2432: 3092.724591527 0.38024 getpid() = 2432 (0x980)
2432: 3092.724952323 0.52955 setuid(0x0)ERR#1 'Operation not permitted'
2432: 3092.727852159 0.42969 clock_gettime(4,{ 21633.960374942 }) = 0 (0x0)
2432: 3092.728508193 0.34327 clock_gettime(4,{ 21633.961033929 }) = 0 (0x0)
2432: 3092.729146608 0.36872 clock_gettime(4,{ 21633.961670903 }) = 0 (0x0)
2432: 3092.729824967 0.38360 clock_gettime(4,{ 21633.962349071 }) = 0 (0x0)
2432: 3092.732435446 0.001634793 exit(0x0)
2432: 3092.732555855 0.001755202 process exit, rval = 0
963: 3092.732638865 0.018571063 SIGNAL 20 (SIGCHLD) code=CLD_EXITED pid=2432
uid=25 status=0
963: 3092.732822864 0.018755062 sigsuspend({ }) ERR#4 'Interrupted system
call'
963: 3092.733076525 0.39968 sigprocmask(SIG_SETMASK,{ SIGCHLD },0x0) = 0
(0x0)
963: 3092.733447788 0.76601 wait4(-1,{ EXITED,val=0 },WNOHANG,0x0) = 2432
(0x980)
963: 3092.733781410 0.34783 wait4(-1,0xbe60,WNOHANG,0x0) ERR#10 'No
child processes'
963: 3092.734065366 0.37328 sigreturn(0xbe90) EJUSTRETURN
963: 3092.734263408 0.33295 sigprocmask(SIG_BLOCK,0x0,{ }) = 0 (0x0)
(No activity in 963 for about 1800 seconds.)
But once it starts failing, the SIGSEGV happens just after the:
setuid(0x0)ERR#1 'Operation not permitted'
For example:
. . .
4745: 37293.335510778 0.35023 clock_gettime(13,{ 1588604405.0 }) =
0 (0x0)
4745: 37293.335754863 0.37593 setitimer(0,{ 0.00, 0.00 },0x0) = 0
(0x0)
4745: 37293.336010253 0.36200 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ }) = 0
(0x0)
4745: 37293.336488027 0.33823 getpid() = 4745 (0x1289)
4745: 37293.336836797 0.51995 setuid(0x0) ERR#1 'Operation not permitted'
4745: 37293.338022675 0.001237873 SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR
trapno=768 addr=0x506a11f0
4745: 37293.339546520 0.002761718 process killed, signal = 11
963: 37293.339627249 0.050797919 SIGNAL 20 (SIGCHLD) code=CLD_KILLED pid=4745
uid=25 status=11
963: 37293.339794781 0.050965451 sigsuspend({ }) ERR#4 'Interrupted system
call'
963: 37293.340038313 0.37544 sigprocmask(SIG_SETMASK,{ SIGCHLD },0x0) = 0
(0x0)
963: 37293.340329951 0.70215 wait4(-1,{ SIGNALED,sig=SIGSEGV
},WNOHANG,0x0) = 4745 (0x1289)
963: 37293.340634048 0.34903 wait4(-1,0xbe60,WNOHANG,0x0) ERR#10 'No
child processes'
963: 37293.340901417 0.37615
zfs.core, 'send' crashing - how to debug offline?
Hello, playing with -current snapshot provides all kinds of surprises :-) The one regarding the topic: 'zfs send' aborts with "invalid argument". The machine in question doesn't have internet access (but local FreeBSD FTP mirror, so I managed to install matching base-dbg). What debugger am I supposed to use these days for -current? Sorry for that ignorant/stupid question – all I know about the transition to llvm/clang is that it's still 'cc' ;-) There's still /usr/libexe/kdgb, but I can't use it for my userland core dump, can I? Not beeing able to dump ZFS is a very severe problem for me and I'd like to provide at least some useful problem reports. Any help highly appreciated, thanks, -harry P.S. No matter if I try to send snapshots or unmounted fielsystems - 'send' is always aborting (scrub doesn't detect inconsistencies). P.P.S.: sendmail(8) is back in base!?! and DMA gone P.P.P.S.: efi\freebsd\loader.efi doesn't work well – raised and already commented by bcran@ P.P.P.P.S: kern.vt.fb.default_mode vs. efi_max_resolution for loader.conf(8) was hard to invalidate reading vt(4) – still completely unsure how/if to change non-KMS UEFI/GOP resolution outside loader(8). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
On 2020-04-27 08:02, Miroslav Lachman wrote: I don't know what is with Scott. I hope he is well. Is there somebody else who can help me with this issue? Scott wrote there are hotplug PCIe buses not probed during boot process. I am not a developer so I cannot move forward alone. The problem is with PCIe Hot Plug. Hot Plug bus was not enumerated thus no NVME detected. Dan Lukes suggested (privately) to disable hot plugging by this at second stage loader prompt: set hw.pci.enable_pcie_hp=0 Then I was able to boot FreeBSD installer ISO in BIOS mode (I don't know why but this machine is not able to boot FreeBSD ISO media in UEFI mode). Installer sees both NVME disks and installation was successful but it cannot boot - Dell R6515 in BIOS mode does not show NVME drives. Switching to UEFI boot shows disks but they didn't contained EFI partition boot code. When I modified the partitions layout (remove swap, ad efi partition and swap again) it is now able to boot FreeBSD 11.3 amd64 in UEFI mode from NVME disks with Hot Plug disabled in loader.conf. Can somebody look on to it why the bus is not probed when Hot Plug is enabled? I have a few days to run some tests on this HW before it will go in to production. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote:
> In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --ma2vde2ykv3k7k6b
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --mvhxgm4zl62unzlf
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> > 20
> > > > > Daroussin wr
> > > > > ites:
> > > > > >=3D20
> > > > > >
> > > > > > --vwrr5drfobpkyvop
> > > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > > Content-Disposition: inline
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > >
> > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> > t th=3D
> > > > at=3D3D
> > > > > > =3D3D20
> > > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> > for =3D
> > > > this=3D3D
> > > > > > =3D3D20
> > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> > t ex=3D
> > > > ist =3D3D
> > > > > > in=3D3D20
> > > > > > > termcap(5). People who want that extra functionality would be adv=
> > ised=3D
> > > > to=3D3D
> > > > > > =3D3D20
> > > > > > > install the alternative pkg or build the sysutils/screen port wit=
> > h th=3D
> > > > e=3D3D20
> > > > > > > appropriate option.
> > > > > > >=3D3D20
> > > > > > > Or, simply change the default from whatever ncurses is available =
> > to a=3D
> > > > lway=3D3D
> > > > > > s=3D3D20
> > > > > > > install devel/ncurses. People could always select one of the othe=
> > r op=3D
> > > > tion=3D3D
> > > > > > s.=3D3D20
> > > > > > > Personally, I'm not enamoured with this approach.
> > > > > >
> > > > > > I think it is a terrible idea, and we should fix the initial proble=
> > m in=3D
> > > > stea=3D3D
> > > > > > d of
> > > > > > workarounding it.
> > > > > >
> > > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> > ey a=3D
> > > > re
> > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > > >=3D20
> > > > > I came to this conclusion last night after sending this email thread =
> > oud=3D
> > > > =3D20
> > > > > and will test it some time today.
> > > > >=3D20
> > > > > >
> > > > > > 2/ we should allow our base ncurses to get informations from newer =
> > term=3D
> > > > cap(=3D3D
> > > > > > 5) if
> > > > > > needed.
> > > > > > So far the default TERMCAP is
> > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> > =2Edb}
> > > > > >
> > > > > > First the user can be advise to point configure the $home/.termcap =
> > this=3D
> > > > is =3D3D
> > > > > > for
> > > > > > quick now.
> > > >
> > > > that is in your scope via a pkg-message :D
> > > >
> > > > > >
> > > > > > Second for later futur proof mechanism we could modify our termcap =
> > read=3D
> > > > er (=3D3D
> > > > > > we
> > > > > > use our own, not the one in provided by ncurses). to be able to fet=
> > ch t=3D
> > > > ermc=3D3D
> > > > > > ap
> > > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > > >
> > > > > > This way ports with random termcap info to add would be able to do =
> > it w=3D
> > > > itho=3D3D
> > > > > > ut
> > > > > > the requirement to wait for a commit in base and a MFC.
> > > > >=3D20
> > > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > > >=3D20
> > > > I will then.
> > > > I added that to my TODO
> > >=20
> > > There's already a utility in devel/ncurses called infotocap (and its=20
> > > corresponding captoinfo) that already does this. Both are links to tic. O=
> > ur=20
> > > ncurses import includes tic. Looks like all that's needed is add it to=20
> > > buildworld.
> > >=20
> > > I can look at it later tonight. Seems like a quick win.
> > >=20
> > That is not the point, tic won't work here except if create your own versio=
> > n or
> > use infotocap. Tic is for terminfo databases while we are still using the=
> > =20
> > termcap for historical reason
>
> I'm not suggesting replacing all of termcap. Just adding some converted
> screen.* entries.
>
> >
> > Having both ncurses from ports and ncurses from base installed at the same =
> > time
> > can open a special can of worm so imho that is not really something we want=
> > to
> > look forward.
>
> Some ports require ncurses from ports. Same can of worms as installing a
> kerberos or openssl port.
>
On head, no ports should have to now.
Best
Re: sysutils/screen-ncurses port
In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --ma2vde2ykv3k7k6b
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > Daroussin wr
> > ites:
> > >=20
> > >
> > > --mvhxgm4zl62unzlf
> > > Content-Type: text/plain; charset=3Dus-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> 20
> > > > Daroussin wr
> > > > ites:
> > > > >=3D20
> > > > >
> > > > > --vwrr5drfobpkyvop
> > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > Content-Disposition: inline
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> t th=3D
> > > at=3D3D
> > > > > =3D3D20
> > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> for =3D
> > > this=3D3D
> > > > > =3D3D20
> > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> t ex=3D
> > > ist =3D3D
> > > > > in=3D3D20
> > > > > > termcap(5). People who want that extra functionality would be adv=
> ised=3D
> > > to=3D3D
> > > > > =3D3D20
> > > > > > install the alternative pkg or build the sysutils/screen port wit=
> h th=3D
> > > e=3D3D20
> > > > > > appropriate option.
> > > > > >=3D3D20
> > > > > > Or, simply change the default from whatever ncurses is available =
> to a=3D
> > > lway=3D3D
> > > > > s=3D3D20
> > > > > > install devel/ncurses. People could always select one of the othe=
> r op=3D
> > > tion=3D3D
> > > > > s.=3D3D20
> > > > > > Personally, I'm not enamoured with this approach.
> > > > >
> > > > > I think it is a terrible idea, and we should fix the initial proble=
> m in=3D
> > > stea=3D3D
> > > > > d of
> > > > > workarounding it.
> > > > >
> > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> ey a=3D
> > > re
> > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > >=3D20
> > > > I came to this conclusion last night after sending this email thread =
> oud=3D
> > > =3D20
> > > > and will test it some time today.
> > > >=3D20
> > > > >
> > > > > 2/ we should allow our base ncurses to get informations from newer =
> term=3D
> > > cap(=3D3D
> > > > > 5) if
> > > > > needed.
> > > > > So far the default TERMCAP is
> > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> =2Edb}
> > > > >
> > > > > First the user can be advise to point configure the $home/.termcap =
> this=3D
> > > is =3D3D
> > > > > for
> > > > > quick now.
> > >
> > > that is in your scope via a pkg-message :D
> > >
> > > > >
> > > > > Second for later futur proof mechanism we could modify our termcap =
> read=3D
> > > er (=3D3D
> > > > > we
> > > > > use our own, not the one in provided by ncurses). to be able to fet=
> ch t=3D
> > > ermc=3D3D
> > > > > ap
> > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > >
> > > > > This way ports with random termcap info to add would be able to do =
> it w=3D
> > > itho=3D3D
> > > > > ut
> > > > > the requirement to wait for a commit in base and a MFC.
> > > >=3D20
> > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > >=3D20
> > > I will then.
> > > I added that to my TODO
> >=20
> > There's already a utility in devel/ncurses called infotocap (and its=20
> > corresponding captoinfo) that already does this. Both are links to tic. O=
> ur=20
> > ncurses import includes tic. Looks like all that's needed is add it to=20
> > buildworld.
> >=20
> > I can look at it later tonight. Seems like a quick win.
> >=20
> That is not the point, tic won't work here except if create your own versio=
> n or
> use infotocap. Tic is for terminfo databases while we are still using the=
> =20
> termcap for historical reason
I'm not suggesting replacing all of termcap. Just adding some converted
screen.* entries.
>
> Having both ncurses from ports and ncurses from base installed at the same =
> time
> can open a special can of worm so imho that is not really something we want=
> to
> look forward.
Some ports require ncurses from ports. Same can of worms as installing a
kerberos or openssl port.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311
This note just reports things from looking at 2
.core files (mountd and rpcbind) from the new
jemalloc context's failures. May be someone that
knows more can get something out of it. I've
not included any of the prior message history.
For mountd:
Core was generated by `/usr/sbin/mountd -r'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x50235df0 in cache_bin_dalloc_easy (bin=,
bin_info=, ptr=0x50049160) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/cache_bin.h:121
warning: Source file is more recent than executable.
121 if (unlikely(bin->ncached == bin_info->ncached_max)) {
It turns out that bin_info traces back to:
cache_bin_t *bin = tcache_small_bin_get(tcache, alloc_ctx.szind);
cache_bin_info_t *bin_info = _bin_info[alloc_ctx.szind];
if (!cache_bin_dalloc_easy(bin, bin_info, ptr)) {
return false;
}
based on:
#define tcache_bin_info JEMALLOC_N(tcache_bin_info)
and:
# define JEMALLOC_N(n) __je_##n
But gdb reports:
(gdb) print __je_tcache_bin_info
$3 = (cache_bin_info_t *) 0x0
(gdb) print alloc_ctx
$1 = {szind = 0, slab = }
so bin_info = NULL and bin_info->ncached_max would
fail (and does).
By contrast, bin->ncached seems to be from:
(gdb) print *(cache_bin_t*)0x50094018
$6 = {low_water = 65536, ncached = 1, tstats = {nrequests =
4796680610075595179}, avail = 0x0}
For rpcbind:
Core was generated by `/usr/sbin/rpcbind'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x50243fec in rendezvous_request (xprt=, msg=) at /usr/src/lib/libc/rpc/svc_vc.c:323
323 newxprt->xp_raddr = *(struct sockaddr_in
*)newxprt->xp_rtaddr.buf;
(gdb) print *newxprt
$5 = {xp_fd = 14, xp_port = 0, xp_ops = 0x50329e1c, xp_addrlen = 0, xp_raddr =
{sin_len = 0 '\000', sin_family = 0 '\000', sin_port = 0, sin_addr = {s_addr =
0},
sin_zero = "\000\000\000\000P1O\374"}, xp_ops2 = 0x50329e34, xp_tp = 0x0,
xp_netid = 0x50047310 "unix", xp_ltaddr = {maxlen = 1345322064, len =
1970170232, buf = 0x2020}, xp_rtaddr = {
maxlen = 268500992, len = 16, buf = 0x0}, xp_verf = {oa_flavor = 0, oa_base
= 0x202d2020 , oa_length =
538976364}, xp_p1 = 0x6f6f7000,
xp_p2 = 0x0, xp_p3 = 0x202d2020, xp_type = 538976288}
so newxprt->xp_rtaddr.buf == 0x0 . But taht is very odd . . .
/*
* make a new transporter (re-uses xprt)
*/
newxprt = makefd_xprt(sock, r->sendsize, r->recvsize);
newxprt->xp_rtaddr.buf = mem_alloc(len);
if (newxprt->xp_rtaddr.buf == NULL)
return (FALSE);
memcpy(newxprt->xp_rtaddr.buf, , len);
newxprt->xp_rtaddr.len = len;
#ifdef PORTMAP
if (addr.ss_family == AF_INET || addr.ss_family == AF_LOCAL) {
newxprt->xp_raddr = *(struct sockaddr_in
*)newxprt->xp_rtaddr.buf;
newxprt->xp_addrlen = sizeof (struct sockaddr_in);
}
#endif /* PORTMAP */
Or, in machine code terms:
0x50243f90 <+260>: mr r28,r3
0x50243f94 <+264>: lwz r4,0(r24)
0x50243f98 <+268>: lwz r5,4(r24)
0x50243f9c <+272>: mr r3,r28
0x50243fa0 <+276>: bl 0x5024308c
0x50243fa4 <+280>: lwz r27,36(r1)
0x50243fa8 <+284>: mr r29,r3
0x50243fac <+288>: li r3,1
0x50243fb0 <+292>: mr r4,r27
0x50243fb4 <+296>: bl 0x502e3214 <.plt_pic32.calloc>
0x50243fb8 <+300>: cmplwi r3,0
0x50243fbc <+304>: stw r3,64(r29)
0x50243fc0 <+308>: beq 0x50244160
Note: getting here means that newxprt->xp_rtaddr.buf
ws not NULL . Also the value was stored to 64(r29).
0x50243fc4 <+312>: addir4,r1,296
0x50243fc8 <+316>: mr r5,r27
0x50243fcc <+320>: bl 0x502e3264 <.plt_pic32.memcpy>
Note: getting here means that memcpy was able to
store where ewxprt->xp_rtaddr.buf indicated (as
the r3 value).
0x50243fd0 <+324>: lbz r3,297(r1)
0x50243fd4 <+328>: stw r27,60(r29)
0x50243fd8 <+332>: addir3,r3,-1
0x50243fdc <+336>: clrlwi r3,r3,24
0x50243fe0 <+340>: cmplwi r3,1
0x50243fe4 <+344>: bgt 0x50244014
0x50243fe8 <+348>: lwz r3,64(r29)
=> 0x50243fec <+352>: lwz r4,0(r3)
Note: the failure was above with r3==0x0:
(gdb) info reg
r0 0x50243fb8 1344552888
r1 0xb400 4294947840
r2 0x500a1018 1342836760
r3 0x0 0
r4 0xb538 4294948152
r5 0x1016
r6 0x50047328 1342468904
r7 0x0 0
r8 0x50047324 1342468900
r9 0x0 0
r100x2032
r110x502d691c 1345153308
r120x24200880 606079104
r130x0 0
r140x0 0
r150xbc28 4294949928
Re: sysutils/screen-ncurses port
On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --mvhxgm4zl62unzlf
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --vwrr5drfobpkyvop
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> > at=3D
> > > > =3D20
> > > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> > this=3D
> > > > =3D20
> > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> > ist =3D
> > > > in=3D20
> > > > > termcap(5). People who want that extra functionality would be advised=
> > to=3D
> > > > =3D20
> > > > > install the alternative pkg or build the sysutils/screen port with th=
> > e=3D20
> > > > > appropriate option.
> > > > >=3D20
> > > > > Or, simply change the default from whatever ncurses is available to a=
> > lway=3D
> > > > s=3D20
> > > > > install devel/ncurses. People could always select one of the other op=
> > tion=3D
> > > > s.=3D20
> > > > > Personally, I'm not enamoured with this approach.
> > > >
> > > > I think it is a terrible idea, and we should fix the initial problem in=
> > stea=3D
> > > > d of
> > > > workarounding it.
> > > >
> > > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> > re
> > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > >=20
> > > I came to this conclusion last night after sending this email thread oud=
> > =20
> > > and will test it some time today.
> > >=20
> > > >
> > > > 2/ we should allow our base ncurses to get informations from newer term=
> > cap(=3D
> > > > 5) if
> > > > needed.
> > > > So far the default TERMCAP is
> > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > > >
> > > > First the user can be advise to point configure the $home/.termcap this=
> > is =3D
> > > > for
> > > > quick now.
> >
> > that is in your scope via a pkg-message :D
> >
> > > >
> > > > Second for later futur proof mechanism we could modify our termcap read=
> > er (=3D
> > > > we
> > > > use our own, not the one in provided by ncurses). to be able to fetch t=
> > ermc=3D
> > > > ap
> > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > >
> > > > This way ports with random termcap info to add would be able to do it w=
> > itho=3D
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > >=20
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > >=20
> > I will then.
> > I added that to my TODO
>
> There's already a utility in devel/ncurses called infotocap (and its
> corresponding captoinfo) that already does this. Both are links to tic. Our
> ncurses import includes tic. Looks like all that's needed is add it to
> buildworld.
>
> I can look at it later tonight. Seems like a quick win.
>
That is not the point, tic won't work here except if create your own version or
use infotocap. Tic is for terminfo databases while we are still using the
termcap for historical reason
Having both ncurses from ports and ncurses from base installed at the same time
can open a special can of worm so imho that is not really something we want to
look forward.
Best regards,
Bapt
signature.asc
Description: PGP signature
