Re: xenodm doesn't login after enabling UTF-8 by setting LC_CTYPE
On 2023-11-26 01:14, Omar Polo wrote: On 2023/11/25 22:02:38 +0700, hahahahacker2...@airmail.cc wrote: > Description: Adding the line export LC_CTYPE="en_US.UTF-8" then login, it just check the password, then fall back to the xenodm login screen. Can't find any log for the error, tried /var/log and logs at ~ but no result. The windows manager is fvwm. > How-To-Repeat: Create ~/.xsession if not already exist, add this line: export LC_CTYPE="en_US.UTF-8" blind guess: if you don't have a `exec $window_manager` line at the end, doesn't the script exit immediately and xenodm assume the session has ended? (sorry for the probably dumb question, but once you have an .xsession file in place you don't have fvwm running by default anymore.) Thank you for helping, your solution worked.
Re: getsockname() reports more bytes in the socket address buffer than what actually exists
On Mon, Nov 27, 2023 at 07:32:57AM +0100, Otto Moerbeek wrote:
> On Sun, Nov 26, 2023 at 07:12:47PM -0800, Dev Email wrote:
>
> > >Sypnosis: getsockname() reports more information in the socket address
> > buffer than what actually exists
> >
> > >Category: library
> >
> > >Environment:
> >
> > System : OpenBSD 7.4
> > Details : OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37
> > MDT 2023
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> >
> > >Description:
> >
> > When calling the "getsockname()" standard C library call, it returns more
> > bytes than the actual length in the
> >
> > resulting socket path. This results in sockets named, for example,
> > "socket123", being represented instead as
> >
> > "socket123\0\0\0\0\0\0\0...". The problem appears to stem from the C library
> > implementation setting the socket
> >
> > name to the maximum length allowed by the socket address rather than the
> > actual name. This is not a problem
> >
> > if you use traditional null-terminated C strings, but becomes a problem in
> > other languages which use the returned
> >
> > length to determine how to use the string.
> >
> >
> > This was found during the course of investigating this issue:
> > https://github.com/rust-lang/rust/issues/116523
> >
> > >How-To-Repeat:
> >
> > I was able to repeat the bug using this C program:
> >
> > ---
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > int main(void) {
> > int server_sock, rc, len, i;
> > struct sockaddr_un address_in, address_out;
> > char address_name[32] = { 0 };
> > char c;
> >
> > server_sock = socket(AF_UNIX, SOCK_STREAM, 0);
> > if (server_sock == -1) {
> > puts("failed to open socket");
> > exit(1);
> > }
> >
> > address_in.sun_family = AF_UNIX;
> > strcpy(address_in.sun_path, "/tmp/socket123");
> > len = strlen("/tmp/socket123") + sizeof(address_in) -
> > sizeof(address_in.sun_path);
> >
> > rc = bind(server_sock, _in, len);
> > if (rc == -1) {
> > puts("failed to bind to socket");
> > exit(1);
> > }
> >
> > len = 1;
> > rc = getsockname(server_sock, _out, );
> > if (rc == -1) {
> > puts("failed to read socket name");
> > exit(1);
> > }
> >
> > len -= (sizeof(address_out) - sizeof(address_out.sun_path));
> > printf("socket address length is %d\n", len);
> >
> > for (i = 0; i < len; i++) {
> > c = address_out.sun_path[i];
> > if (c >= 33 && c <= 126) {
> > printf("%c", c);
> > } else {
> > printf("\\%d", c);
> > }
> > }
> > printf("\n");
> >
> > close(server_sock);
> > return 0;
> > }
> >
> > ---
> >
> > When run on a Linux machine, it produces this output:
> >
> > ---
> >
> > $ cc bug.c -o bug
> >
> > $ ./bug
> >
> > socket address length is 15
> > /tmp/socket123\0
> >
> > ---
> >
> > I receive the same output on FreeBSD and NetBSD.
> >
> > When run on OpenSBD 7.4, it produces this output:
> >
> > ---
> >
> > $ cc bug.c -o bug
> >
> > $ ./bug
> >
> > socket address length is 104
> > /tmp/socket123\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
> >
> > \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
> >
> >
> > ---
> >
> > Ideally, OpenBSD would return the same output.
> >
> > >Fix:
> >
> > This could be fixed by returning the actual length of the socket address in
> > the "len" variable
> >
> > in the "getsockname" function.
> >
> >
> > I don't believe that dmesg is relevant for this bug; I can provide it if
> > requested.
> >
>
> I'm not 10%% convinced it is a bug, there's is something to be said
> for setting len to sizeof(struct sockaddr_un).
>
> getsockname is underspecified in Posix Unix domain sockets, the other
> address families use fixed size structs.
>
> FreeBSD's man page even says it is unsupported for Unix domain
> sockets. So I'm undecided, other devs might have stronger opinions.
>
I agree with what Otto said. The len returned is the len of the sockname_un
struct. On the other hand on OpenBSD the returned sun_path is always a C
string. So there is no need to look at the length.
Finally I'm surprised that your example code is actually working. The len
argument in the getsockname() call is wrong in multiple ways.
--
:wq Claudio
Re: getsockname() reports more bytes in the socket address buffer than what actually exists
On Mon, Nov 27, 2023 at 07:32:57AM +0100, Otto Moerbeek wrote: > On Sun, Nov 26, 2023 at 07:12:47PM -0800, Dev Email wrote: > > > Ideally, OpenBSD would return the same output. > > > > >Fix: > > > > This could be fixed by returning the actual length of the socket address in > > the "len" variable > > > > in the "getsockname" function. > > > > > > I don't believe that dmesg is relevant for this bug; I can provide it if > > requested. > > > > I'm not 10%% convinced it is a bug, there's is something to be said > for setting len to sizeof(struct sockaddr_un). > It's documented: "namelen indicates the amount of space pointed to by name, in bytes." So, yes, for AF_UNIX sockets it is sizeof(struct sockaddr_un). > getsockname is underspecified in Posix Unix domain sockets, the other > address families use fixed size structs. > > FreeBSD's man page even says it is unsupported for Unix domain > sockets. So I'm undecided, other devs might have stronger opinions. > > -Otto >
Re: zzz failing and uvn_flush errors
Den mån 27 nov. 2023 kl 09:15 skrev Laurence Tratt : > > Yesterday my amd64 machine failed to `zzz` for the first time (with a > kernel built from yesterday with the now-commited "support Alder Lake-N and > Alder Lake-S" from jsg@). This might just be one of those random things > that we so love about computers but after reboot I had `uvn_flush` errors > and warnings in my dmesg, which I don't remember having seen before. I used to get them on systems with too small /usr. The 'uvn_flush' thing is related to using mmap() for file IO and it failing to map out space on disk when the partition/filesystem is 100% full. So totally related, from what I understand. -- May the most significant bit of your life be positive.
zzz failing and uvn_flush errors
Yesterday my amd64 machine failed to `zzz` for the first time (with a kernel built from yesterday with the now-commited "support Alder Lake-N and Alder Lake-S" from jsg@). This might just be one of those random things that we so love about computers but after reboot I had `uvn_flush` errors and warnings in my dmesg, which I don't remember having seen before. Those errors seemed to start at the same point that a long-lived process had managed to stop /tmp from freeing space up. That might just be coincidence, but one side effect of /tmp filling up these days is that Chrome-based browser and Firefox both tend to exit without any indication of why. Here's the probably-relevant part of the dmesg: uid 1000 on /tmp: file system full uid 1000 on /tmp: file system full uvn_flush: obj=0xfd8ace67dee8, offset=0x3. error during pageout. uvn_flush: WARNING: changes to page may be lost! uid 1000 on /tmp: file system full uvn_flush: obj=0xfd8ace67dad8, offset=0x2. error during pageout. uvn_flush: WARNING: changes to page may be lost! uid 1000 on /tmp: file system full uid 1000 on /tmp: file system full drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A uid 1000 on /tmp: file system full drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A drm:pid56681:intel_pipe_update_end *ERROR* [drm] *ERROR* Atomic update failure on pipe A (start=32449 end=32450) time 2 us, min 2544, max 2559, scanline start 2554, end 2559 drm:pid56681:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A uhid0 detached uhidev0 detached ugen0 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout uaudio0: can't reset interface xhci0: command ring abort timeout uaudio0: can't reset interface audio1 detached uaudio0 detached midi0 detached xhci0: command ring abort timeout xhci0: command ring abort timeout umidi0 detached ugen1 detached xhci0: command ring abort timeout xhci0: command ring abort timeout video0 detached uvideo0 detached audio2 detached uaudio1 detached uhid1 detached uhidev1 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout wskbd1: disconnecting from wsdisplay0 wskbd1 detached ukbd0 detached uhidev2 detached xhci0: command ring abort timeout uhid2 detached wskbd2: disconnecting from wsdisplay0 wskbd2 detached ucc0 detached uhidev3 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout uhub1 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout wskbd3: disconnecting from wsdisplay0 wskbd3 detached ukbd1 detached uhidev4 detached xhci0: command ring abort timeout wsmouse0 detached ums0 detached wskbd4: disconnecting from wsdisplay0 wskbd4 detached ucc1 detached uhid3 detached uhid4 detached uhidev5 detached xhci0: command ring abort timeout uhidpp0 detached uhid5 detached uhid6 detached uhidev6 detached xhci0: command ring abort timeout xhci0: command ring abort timeout sd1 detached scsibus3 detached xhci0: command ring abort timeout xhci0: command ring abort timeout umass0 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout uhub2 detached xhci0: command ring abort timeout xhci0: command ring abort timeout ugen2 detached xhci0: command ring abort timeout xhci0: command ring abort timeout xhci0: command ring abort timeout uhub3 detached xhci0: command ring abort timeout xhci0: command ring abort timeout uhub0 detached Note that the kernel never got to "syncing disks" (and I left it for at least an hour). The full dmesg is as follows: OpenBSD 7.4-current (GENERIC.MP) #1: Sun Nov 26 14:20:54 GMT 2023 ltr...@overdrive.tratt.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68431814656 (65261MB) avail mem = 66338222080 (63265MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x75a58000 (104 entries) bios0: vendor American Megatrends Inc. version "1501" date 10/05/2023 bios0: ASUS ROG STRIX Z790-H GAMING WIFI efi0 at bios0: UEFI 2.8 efi0: American Megatrends rev 0x5001b acpi0 at bios0: ACPI 6.4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT HPET
