misc/screen segfault

[developer]

Hi,

I installed the misc/screen port.

Anybody knows why this happens on arm64 ?

ws-4# uname -a
OpenBSD ws-4.my.domain 7.3 GENERIC.MP#2164 arm64

ws-4# screen -v
Segmentation fault (core dumped)


No problem with amd64:

ws-3# uname -a
OpenBSD ws-3.my.domain 7.3 GENERIC#1072 amd64

ws-3# screen -v
Screen version 4.09.00 (GNU) 30-Jan-22

Thank you.

Re: misc/screen segfault

[developer]

Quoting Theo Buehler :


Anybody knows why this happens on arm64 ?

ws-4# uname -a
OpenBSD ws-4.my.domain 7.3 GENERIC.MP#2164 arm64

ws-4# screen -v
Segmentation fault (core dumped)


Does not happen here. Could you provide a backtrace, please?

# pkg_delete screen
# pkg_add gdb debug-screen

Then reproduce the crash and at the gdb prompt type 'bt' and share the
output, please.

# egdb screen screen.core
(gdb) bt


Thank you for your instructions! Here you go:

ws-4# pkg_delete screen
screen-4.9.0|   
   
 |  
0%Invalid \0 character in pathname for ftlink: SPCRP\0 at  
/usr/libdata/perl5/OpenBSD/Delete.pm line 432.
Invalid \0 character in pathname for ftfile: SPCRP\0 at  
/usr/libdata/perl5/OpenBSD/Delete.pm line 436.
File SPCRP�BOCHS BXPC 
BXPC???	??!?DBG2W�BOCHS BXPCBXPC,+&?"	COM0?? does not  
exist
Use of uninitialized value $name in pattern match (m//) at  
/usr/libdata/perl5/OpenBSD/PackageInfo.pm line 111.
Use of uninitialized value $name in concatenation (.) or string at  
/usr/libdata/perl5/OpenBSD/PackageInfo.pm line 114.
Use of uninitialized value $p in delete at  
/usr/libdata/perl5/OpenBSD/PackageInfo.pm line 82.
Use of uninitialized value $s in pattern match (m//) at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 71.
Use of uninitialized value $s in transliteration (tr///) at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 81.
Use of uninitialized value $stem in hash element at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 124.
Use of uninitialized value $pkgname in delete at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 124.
Use of uninitialized value $stem in hash element at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 125.
Use of uninitialized value $stem in delete at  
/usr/libdata/perl5/OpenBSD/PackageName.pm line 126.

screen-4.9.0: ok


ws-4# pkg_add gdb debug-screen
quirks-6.133 signed on 2023-06-19T09:15:25Z
gdb-9.2p3:sqlite3-3.41.2p0: ok
gdb-9.2p3:libffi-3.4.4: ok
gdb-9.2p3:bzip2-1.0.8p0: ok
gdb-9.2p3:xz-5.4.3: ok
gdb-9.2p3:python-3.10.11p0: ok
gdb-9.2p3: ok
Collision in screen-4.9.0: the following files already exist
/usr/local/bin/screen from screen-4.9.0 (different checksum)
/

Re: misc/screen segfault

[developer]

Quoting Theo Buehler :


On Wed, Jun 21, 2023 at 08:22:54PM +0200, develo...@robert-palm.de wrote:


Quoting Theo Buehler :

> > Anybody knows why this happens on arm64 ?
> >
> > ws-4# uname -a
> > OpenBSD ws-4.my.domain 7.3 GENERIC.MP#2164 arm64
> >
> > ws-4# screen -v
> > Segmentation fault (core dumped)
>
> Does not happen here. Could you provide a backtrace, please?
>
> # pkg_delete screen
> # pkg_add gdb debug-screen
>
> Then reproduce the crash and at the gdb prompt type 'bt' and share the
> output, please.
>
> # egdb screen screen.core
> (gdb) bt

Thank you for your instructions! Here you go:

ws-4# pkg_delete screen
screen-4.9.0|
| 0%Invalid \0 character in pathname for ftlink: SPCRP\0 at


Whoa. This and all the other noise that shouldn't be there smell like
you have some file system corruption. Also, there is BOCHS showing up...
Is this virtualized?

I would suggest that you run

sysupgrade -s
pkg_check
pkg_add -uV

and try again.



Yes it's a cloud instance. I used a snapshot image from 18th June or so.

ws-4# sysupgrade -s
Fetching from https://ftp.hostserver.de/pub/OpenBSD/snapshots/arm64/
SHA256.sig   100% |*|  1544   00:00
Signature Verified
INSTALL.arm64 100% || 39925   00:00
base73.tgz   100% |*|   266 MB00:07
bsd  100% |*| 15873 KB00:00
bsd.mp   100% |*| 15943 KB00:00
bsd.rd   100% |*| 17511 KB00:00
comp73.tgz   100% |*| 71020 KB00:02
game73.tgz   100% |*|  2720 KB00:00
man73.tgz100% |*|  7836 KB00:00
xbase73.tgz  100% |*| 48886 KB00:01
xfont73.tgz  100% |*| 22968 KB00:00
xserv73.tgz  100% |*| 10570 KB00:00
xshare73.tgz 100% |*|  4585 KB00:00
Verifying sets.
Fetching updated firmware.
fw_update: added none; updated none; kept none
Upgrading.


Then my ssh connection was killed and machine got stuck (see attached  
screenshot). Did a reboot then.



ws-4# pkg_check
Packing-list sanity: ok
Direct dependencies: ok
Reverse dependencies: ok
Files from packages: ok

ws-4# pkg_add -uV
quirks-6.133 signed on 2023-06-19T09:15:25Z


ws-4# pkg_delete screen
can't delete screen-4.9.0 without deleting debug-screen-4.9.0
Delete them as well ? [y/N/a] y
debug-screen-4.9.0: ok
screen-4.9.0: ok
Read shared items: ok
--- -screen-4.9.0 ---
You should also remove /etc/screenrc (which was modified)
ws-4# pkg_add gdb debug-screen
quirks-6.133 signed on 2023-06-19T09:15:25Z
debug-screen-4.9.0:screen-4.9.0: ok
debug-screen-4.9.0: ok

ws-4# egdb screen screen.core
GNU gdb (GDB) 9.2
Copyright (C) 2020 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 "aarch64-unknown-openbsd7.3".
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 screen...
Reading symbols from /usr/local/bin/.debug/screen.dbg...
[New process 330663]
Core was generated by `screen'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x001341903958 in ?? ()
(gdb) bt
#0  0x001341903958 in ?? ()
#1  0x00134190377c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Re: misc/screen segfault

[developer]

Quoting Theo Buehler :


ws-4# egdb screen screen.core


If this screen.core is new, i.e. generated with a crash after reboot
and screen added after 'pkg_add debug-screen', then I'm out of ideas.

If not, reproduce again and get a new backtrace. If it looks anything
like the one you got (i.e., hex numbers and ??) then it won't help.


#0  0x001341903958 in ?? ()
(gdb) bt
#0  0x001341903958 in ?? ()
#1  0x00134190377c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


Okay, many thanks for all your suggestions!

Program works although there is this segfault error still.

Will come back to it next weeks.

Re: lang/* BTI breakage - lang/sbcl

[developer]

Zitat von Theo de Raadt :


Sebastien Marie  wrote:

sbcl compilation works by generating native code inside live  
managed memory, and

permits to save the whole memory image to a file.

it is why the binary currently also needs WX and RX memory (I  
intent to work a

bit on it if possible).

When generating an executable, it is copying /usr/local/bin/sbcl  
binary as base,

and append the (optionally compressed) memory image to the file, to create a
standalone executable.

When the output file is executed, it is reading its own image, loads it in
memory, and use an entrypoint for loaded code.

So the generated file has all the flags it needs to run (because copied from
/usr/local/bin/sbcl binary).


It is ridiculous.

Even emacs stopped doing that.


Out of interest - what exactly? What changed in Emacs? Thanks.

Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER

[developer]

Zitat von Sebastien Marie :


Hi,

With latest changes on ecl, we are able to update sbcl to latest  
version (2.3.6).


As maintainer systematically timeout since several years now, I am  
taking over
the maintainership (and no reply on private mail asking about  
continuing or not

to maintain lang/sbcl).

I have mostly rewritten the port to ease testing building it with several
bootstraps (ecl, clisp, sbcl) on one architecture, and drop some historical
parts.

Regarding the way to build sbcl, it defaults to using lang/ecl (which is
portable as written in C), and use clisp for some archs only (amd64  
and powerpc,

as currently) as it is more fast.


The mail includes:
- a proper tarball (as for a new port)
- a diff (for braves diff readers)

I tested:
- on amd64, building with clisp (default), ecl and sbcl (2.2.5p0 and 2.3.6)
- on aarch64, building with ecl, and sbcl (2.3.6)
- all dependencies are still building on amd64

The port is buildable on wider architectures range.

Comments or OK ?
--
Sebastien Marie


Thank you. Will it be available for RISC V, too ?

Re: devel/sdl2-net: specify full shared lib filename in cmake file

[developer]

Slightly off topic, but any plans for SDL 3?




 https://github.com/libsdl-org/SDL/releases/tag/release-3.2.0








 On Wed Apr 16, 2025 at 09:23:50PM -0600, Anthony J. Bentley wrote:


  + endif()