xfontsel segmentation fault
>Synopsis: xfontsel segmentation faults with -pattern
>Category: user
>Environment:
System : OpenBSD 7.5
Details : OpenBSD 7.5-current (GENERIC.MP) #98: Thu May 30 21:14:11
MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
xfontsel will crash with a segmentation fault after pressing
'reset' if called with a -pattern option in the form
'*[text without '-']*'.
>How-To-Repeat:
Run xfontsel with a -pattern of '*a*'
(though any pattern of the form '*[text without '-']*' will work)
Do not select any field (fndry,fmly,etc).
Click the 'reset' button.
>Fix:
This is caused by a dereference of the global variable 'choiceList'
which remains NULL in this case. The following diff checks if
choiceList is NULL before dereferencing it.
A better fix might be to figure out why 'choiceList' does not get
set in this situation, but I don't really understand this code.
diff /usr/xenocara
commit - c678468c11876f84f0f8ec2e830769e42df90c15
path + /usr/xenocara
blob - 400eb09ddb1f4b6bc6298f01f19f79397709f689
file + app/xfontsel/xfontsel.c
--- app/xfontsel/xfontsel.c
+++ app/xfontsel/xfontsel.c
@@ -1320,7 +1320,7 @@ static void EnableRemainingItems(ValidateAction curren
FieldValue *value = fieldValues[field]->value;
int count;
if (current_field_action == SkipCurrentField &&
- field == choiceList->value->field)
+ choiceList != NULL && field == choiceList->value->field)
continue;
for (count = fieldValues[field]->count; count; count--, value++) {
int *fp = value->font;
Pasting fails in cwm menus
Synopsis: cwm: X selections cannot be pasted into menus
Category: user
Environment:
System : OpenBSD 7.5
Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
Description:
Attempting to paste an X selection into any of the cwm menus results
in display of a character placeholder, rather than the selection
text. This bug is found in both 7.5 and -current.
How-To-Repeat:
Within cwm, add text to an X selection buffer. Recall a menu using a key or
mouse binding, and attempt to paste the selection.
Fix:
Add to menu.c:menu_handle_key() a CTL_PASTE keysym for the XK_V and
XK_v control characters (and maybe others), and add a handler to the
menu that gets the selection.
Below is a first attempt at this approach, based on a quick look at
sselp (https://tools.suckless.org/x/sselp/) and xclip
(https://github.com/astrand/xclip).
Index: menu.c
===
RCS file: /cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.110
diff -u -p -u -p -r1.110 menu.c
--- menu.c 15 Oct 2022 16:06:07 - 1.110
+++ menu.c 1 Jun 2024 06:04:18 -
@@ -44,7 +44,7 @@
enum ctltype {
CTL_NONE = -1,
CTL_ERASEONE = 0, CTL_WIPE, CTL_UP, CTL_DOWN, CTL_RETURN,
- CTL_TAB, CTL_ABORT, CTL_ALL
+ CTL_TAB, CTL_ABORT, CTL_ALL, CTL_PASTE
};
struct menu_ctx {
@@ -78,6 +78,62 @@ static void menu_draw_entry(struct me
static int menu_calc_entry(struct menu_ctx *, int, int);
static struct menu *menu_complete_path(struct menu_ctx *);
static int menu_keycode(XKeyEvent *, enum ctltype *, char *);
+voidgetsel(struct menu_ctx *, char[]);
+static size_t mach_itemsize(int);
+
+static size_t
+mach_itemsize(int format)
+{
+ if (format == 8)
+ return sizeof(char);
+ if (format == 16)
+ return sizeof(short);
+ if (format == 32)
+ return sizeof(long);
+ return 0;
+}
+
+void
+getsel(struct menu_ctx *mc, char result[])
+{
+ XEvent ev;
+ Window w;
+ Atom typeret;
+ static Atom utf8_string;
+ static Atom xa_clip_string;
+ unsigned long items, len, remain;
+ int format, rc;
+ unsigned char *data = NULL;
+
+ w = mc->win;
+
+ if (!utf8_string)
+ utf8_string = XInternAtom(X_Dpy, "UTF8_STRING", False);
+ if (!xa_clip_string)
+ xa_clip_string = XInternAtom(X_Dpy, "_SELOUT_STRING", False);
+
+ XConvertSelection(X_Dpy, XA_PRIMARY, utf8_string, xa_clip_string, w,
+ CurrentTime);
+
+ do {
+ XNextEvent(X_Dpy, &ev);
+ if (ev.type == SelectionNotify) {
+ rc = XGetWindowProperty(X_Dpy, w,
+ ev.xselection.property, 0, 4096L, False,
+ AnyPropertyType, &typeret, &format, &items,
+ &remain, &data);
+ XDeleteProperty(X_Dpy, w, ev.xselection.property);
+ if (rc == Success) {
+ len = MIN(items * mach_itemsize(format),
+ sizeof(mc->searchstr));
+ memcpy(result, data, len);
+ XFree(data);
+ result[len] = '\0';
+ }
+ break;
+ }
+ } while (ev.xselection.property != None);
+}
struct menu *
menu_filter(struct screen_ctx *sc, struct menu_q *menuq, const char *prompt,
@@ -221,11 +277,12 @@ menu_handle_key(XEvent *e, struct menu_c
struct menu_q *resultq)
{
struct menu *mi;
+ size_t len;
enum ctltype ctl;
+ int clen, i;
+ char seltext[sizeof(mc->searchstr)];
+ wchar_t wc;
char chr[32];
- size_t len;
- int clen, i;
- wchar_t wc;
if (menu_keycode(&e->xkey, &ctl, chr) < 0)
return NULL;
@@ -304,6 +361,11 @@ menu_handle_key(XEvent *e, struct menu_c
case CTL_ALL:
mc->list = !mc->list;
break;
+ case CTL_PASTE:
+ getsel(mc, seltext);
+ (void)strlcat(mc->searchstr, seltext, sizeof(mc->searchstr));
+ mc->changed = 1;
+ break;
case CTL_ABORT:
mi = xmalloc(sizeof(*mi));
mi->text[0] = '\0';
@@ -557,6 +619,10 @@ menu_keycode(XKeyEvent *ev, enum ctltype
case XK_a:
case XK_A:
*ctl = CTL_ALL;
+ break;
+ case XK_v:
+ case XK_V:
+
Re: Performance issue on 7.5
Le 01/06/2024 à 14:04, Matthieu Herrb a écrit : On Sat, Jun 01, 2024 at 11:57:35AM +0200, Sacha wrote: Dear list, We have a performance issue impacting all our infrastructure behind our OpenBSD: two front BGP/CARP routers with 1Gb/s transit. It seams to occur since we have upgraded to 7.5, both of the servers are up to date. Hi Sacha, Can you check the traffic on the pfsync link ? If it's abnormally high, it may be part of the problem and the patch in https://marc.infœ?l=openbsd-tech&m=171605571513642&w=2 may help. Salut Matthieu, glad to have new from you :) No pfsync link: no pf on the front routers. Sacha.
Re: Upgrade to OpenBSD 7.5 broke the bsd game of cribbage
Otto Moerbeek wrote:
> On Wed, May 29, 2024 at 08:05:14AM +0200, Otto Moerbeek wrote:
>
> > On Mon, May 27, 2024 at 09:21:34PM -0500, Don Wilburn wrote:
> >
> > > Dear OpenBSD,
> > >
> > > I recently upgraded from version 7.4 to 7.5. This broke the old cribbage
> > > game. This is included with OpenBSD, if you choose to install the games.
> > >
> > > I'm not a programmer, but I promise you this happened because ncurses was
> > > updated from version 5.7 to 6.4
> > >
> > > The problem:
> > >
> > > Normally the game gives prompts for play options and cards. It's supposed
> > > to leave the prompt after the response, then advance to a new line. This
> > > gives a brief history of selections
> > >
> > > Now, starting with the third prompt (cut the cards), the prompts
> > > disappear
> > > when a response key is pressed. This ruins the game. The effect is
> > > obvious,
> > > even if you don't know how to play cribbage.
> > >
> > > It would be even more obvious if you have an older system to compare with
> > > a
> > > current v7.5 system.
> > >
> > > This happened to linux bsd-games many years ago. A search will indicate
> > > that I filed this same bug with Gentoo linux over 9 years ago. Linux
> > > classic bsd-games has been unmaintained since before that time. This is
> > > where I observed that the bug happened with a ncurses update. Nobody
> > > pursued the solution.
> > >
> > > I don't have the skills to butcher the game code to work with with the
> > > update of ncurses. Likewise, I don't know how to use a debugger or write
> > > a
> > > sample program to replicate the effect. I can't demonstrate WHY ncurses
> > > is
> > > the problem. Maybe it's the C compiler's fault?
> > >
> > > I still play this obsolete command line game. It's nostalgia, I guess. I
> > > know OpenBSD developers have really important things to maintain. If
> > > someone could spare some time for this little bug, I'd be happy. Maybe it
> > > could be delegated to a student?
> > >
> > > Thanks for reading, DW
> > >
> >
> > One remains a student forever.
> >
> > Try this, it does not try to cut corners with switching windows.
>
> No response from the original reporter.
>
> Is anybody else interested in testing/reviewing?
>
> -Otto
Hi Otto,
I can confirm the behaviour reported by Don Wilburn and that your diff
fixes the issue. I have no idea how to play cribbage, but as Don noted,
the impact is obvious.
FWIW, your fix makes sense to me. A changed line runs to 86 columns as
annotated inline but in the cribbage tree there seems to be instances
where its reflowed to fit within 80 and others where it doesn't.
> >
> > Index: io.c
> > ===
> > RCS file: /home/cvs/src/games/cribbage/io.c,v
> > diff -u -p -r1.22 io.c
> > --- io.c10 Jan 2016 13:35:09 - 1.22
> > +++ io.c29 May 2024 06:00:03 -
> > @@ -505,14 +505,11 @@ get_line(void)
> > {
> > size_t pos;
> > int c, oy, ox;
> > - WINDOW *oscr;
> >
> > - oscr = stdscr;
> > - stdscr = Msgwin;
> > - getyx(stdscr, oy, ox);
> > - refresh();
> > + getyx(Msgwin, oy, ox);
> > + wrefresh(Msgwin);
> > /* loop reading in the string, and put it in a temporary buffer */
> > - for (pos = 0; (c = readchar()) != '\n'; clrtoeol(), refresh()) {
> > + for (pos = 0; (c = readchar()) != '\n'; wclrtoeol(Msgwin),
> > wrefresh(Msgwin)) {
The above line runs to 86 columns, perhaps:
for (pos = 0; (c = readchar()) != '\n';
wclrtoeol(Msgwin), wrefresh(Msgwin)) {
> > if (c == -1)
> > continue;
> > if (c == ' ' && (pos == 0 || linebuf[pos - 1] == ' '))
> > @@ -522,13 +519,13 @@ get_line(void)
> > int i;
> > pos--;
> > for (i = strlen(unctrl(linebuf[pos])); i; i--)
> > - addch('\b');
> > + waddch(Msgwin, '\b');
> > }
> > continue;
> > }
> > if (c == killchar()) {
> > pos = 0;
> > - move(oy, ox);
> > + wmove(Msgwin, oy, ox);
> > continue;
> > }
> > if (pos >= LINESIZE - 1 || !(isalnum(c) || c == ' ')) {
> > @@ -538,12 +535,11 @@ get_line(void)
> > if (islower(c))
> > c = toupper(c);
> > linebuf[pos++] = c;
> > - addstr(unctrl(c));
> > + waddstr(Msgwin, unctrl(c));
> > Mpos++;
> > }
> > while (pos < sizeof(linebuf))
> > linebuf[pos++] = '\0';
> > - stdscr = oscr;
> > return (linebuf);
> > }
> >
> >
--
Mark Jamsek
GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68
Re: Upgrade to OpenBSD 7.5 broke the bsd game of cribbage
On Wed, May 29, 2024 at 08:05:14AM +0200, Otto Moerbeek wrote:
> On Mon, May 27, 2024 at 09:21:34PM -0500, Don Wilburn wrote:
>
> > Dear OpenBSD,
> >
> > I recently upgraded from version 7.4 to 7.5. This broke the old cribbage
> > game. This is included with OpenBSD, if you choose to install the games.
> >
> > I'm not a programmer, but I promise you this happened because ncurses was
> > updated from version 5.7 to 6.4
> >
> > The problem:
> >
> > Normally the game gives prompts for play options and cards. It's supposed
> > to leave the prompt after the response, then advance to a new line. This
> > gives a brief history of selections
> >
> > Now, starting with the third prompt (cut the cards), the prompts disappear
> > when a response key is pressed. This ruins the game. The effect is obvious,
> > even if you don't know how to play cribbage.
> >
> > It would be even more obvious if you have an older system to compare with a
> > current v7.5 system.
> >
> > This happened to linux bsd-games many years ago. A search will indicate
> > that I filed this same bug with Gentoo linux over 9 years ago. Linux
> > classic bsd-games has been unmaintained since before that time. This is
> > where I observed that the bug happened with a ncurses update. Nobody
> > pursued the solution.
> >
> > I don't have the skills to butcher the game code to work with with the
> > update of ncurses. Likewise, I don't know how to use a debugger or write a
> > sample program to replicate the effect. I can't demonstrate WHY ncurses is
> > the problem. Maybe it's the C compiler's fault?
> >
> > I still play this obsolete command line game. It's nostalgia, I guess. I
> > know OpenBSD developers have really important things to maintain. If
> > someone could spare some time for this little bug, I'd be happy. Maybe it
> > could be delegated to a student?
> >
> > Thanks for reading, DW
> >
>
> One remains a student forever.
>
> Try this, it does not try to cut corners with switching windows.
No response from the original reporter.
Is anybody else interested in testing/reviewing?
-Otto
>
> Index: io.c
> ===
> RCS file: /home/cvs/src/games/cribbage/io.c,v
> diff -u -p -r1.22 io.c
> --- io.c 10 Jan 2016 13:35:09 - 1.22
> +++ io.c 29 May 2024 06:00:03 -
> @@ -505,14 +505,11 @@ get_line(void)
> {
> size_t pos;
> int c, oy, ox;
> - WINDOW *oscr;
>
> - oscr = stdscr;
> - stdscr = Msgwin;
> - getyx(stdscr, oy, ox);
> - refresh();
> + getyx(Msgwin, oy, ox);
> + wrefresh(Msgwin);
> /* loop reading in the string, and put it in a temporary buffer */
> - for (pos = 0; (c = readchar()) != '\n'; clrtoeol(), refresh()) {
> + for (pos = 0; (c = readchar()) != '\n'; wclrtoeol(Msgwin),
> wrefresh(Msgwin)) {
> if (c == -1)
> continue;
> if (c == ' ' && (pos == 0 || linebuf[pos - 1] == ' '))
> @@ -522,13 +519,13 @@ get_line(void)
> int i;
> pos--;
> for (i = strlen(unctrl(linebuf[pos])); i; i--)
> - addch('\b');
> + waddch(Msgwin, '\b');
> }
> continue;
> }
> if (c == killchar()) {
> pos = 0;
> - move(oy, ox);
> + wmove(Msgwin, oy, ox);
> continue;
> }
> if (pos >= LINESIZE - 1 || !(isalnum(c) || c == ' ')) {
> @@ -538,12 +535,11 @@ get_line(void)
> if (islower(c))
> c = toupper(c);
> linebuf[pos++] = c;
> - addstr(unctrl(c));
> + waddstr(Msgwin, unctrl(c));
> Mpos++;
> }
> while (pos < sizeof(linebuf))
> linebuf[pos++] = '\0';
> - stdscr = oscr;
> return (linebuf);
> }
>
>
Re: Performance issue on 7.5
On Sat, Jun 01, 2024 at 11:57:35AM +0200, Sacha wrote: > Dear list, > > We have a performance issue impacting all our infrastructure behind our > OpenBSD: two front BGP/CARP routers with 1Gb/s transit. It seams to occur > since we have upgraded to 7.5, both of the servers are up to date. Hi Sacha, Can you check the traffic on the pfsync link ? If it's abnormally high, it may be part of the problem and the patch in https://marc.infœ?l=openbsd-tech&m=171605571513642&w=2 may help. -- Matthieu Herrb
Performance issue on 7.5
Dear list, We have a performance issue impacting all our infrastructure behind our OpenBSD: two front BGP/CARP routers with 1Gb/s transit. It seams to occur since we have upgraded to 7.5, both of the servers are up to date. A simple ssh (without login) on our the router have notable performance issue: * Usual operational state router$ top -s 1 CPU00: 0.2% user, 0.0% nice, 1.0% sys, 0.8% spin, 24.7% intr, 73.3% idle CPU01: 3.6% user, 0.0% nice, 20.1% sys, 1.4% spin, 0.0% intr, 74.9% idle CPU02: 4.7% user, 0.0% nice, 15.9% sys, 1.4% spin, 0.0% intr, 78.0% idle CPU03: 0.0% user, 0.0% nice, 3.0% sys, 1.0% spin, 0.0% intr, 96.0% idle CPU04: 0.0% user, 0.0% nice, 0.8% sys, 0.0% spin, 0.0% intr, 99.2% idle CPU05: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU06: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU07: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU08: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU09: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU10: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU11: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle observer# ping -i 0.1 router […] 64 bytes from router: icmp_seq=122 ttl=255 time=0.242 ms 64 bytes from router: icmp_seq=123 ttl=255 time=0.232 ms 64 bytes from router: icmp_seq=124 ttl=255 time=0.257 ms 64 bytes from router: icmp_seq=125 ttl=255 time=0.316 ms 64 bytes from router: icmp_seq=126 ttl=255 time=0.244 ms 64 bytes from router: icmp_seq=127 ttl=255 time=0.265 ms 64 bytes from router: icmp_seq=128 ttl=255 time=0.333 ms 64 bytes from router: icmp_seq=129 ttl=255 time=0.239 ms 64 bytes from router: icmp_seq=130 ttl=255 time=0.338 ms 64 bytes from router: icmp_seq=131 ttl=255 time=0.375 ms 64 bytes from router: icmp_seq=132 ttl=255 time=0.400 ms 64 bytes from router: icmp_seq=133 ttl=255 time=0.275 ms * On ssh connection (even with no auth key): joe$ ssh foo@router foo@router: Permission denied (publickey). router$ top -s 1 CPU00: 0.0% user, 0.0% nice, 5.8% sys, 1.9% spin, 65.0% intr, 27.2% idle CPU01: 0.0% user, 0.0% nice, 12.6% sys, 16.5% spin, 0.0% intr, 70.9% idle CPU02: 1.9% user, 0.0% nice, 11.7% sys, 36.9% spin, 0.0% intr, 49.5% idle CPU03: 0.0% user, 0.0% nice, 1.9% sys, 1.0% spin, 0.0% intr, 97.1% idle CPU04: 0.0% user, 0.0% nice, 0.0% sys, 1.0% spin, 0.0% intr, 99.0% idle CPU05: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU06: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU07: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU08: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU09: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU10: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU11: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle cpu0 goes 65% intr here, quite often we can see 100% and the spin time skyrockets observer# ping -i 0.1 router […] 64 bytes from router: icmp_seq=524 ttl=255 time=0.242 ms 64 bytes from router: icmp_seq=525 ttl=255 time=0.360 ms 64 bytes from router: icmp_seq=526 ttl=255 time=0.279 ms 64 bytes from router: icmp_seq=527 ttl=255 time=568.051 ms 64 bytes from router: icmp_seq=528 ttl=255 time=468.094 ms 64 bytes from router: icmp_seq=529 ttl=255 time=433.769 ms 64 bytes from router: icmp_seq=530 ttl=255 time=334.208 ms 64 bytes from router: icmp_seq=531 ttl=255 time=234.224 ms 64 bytes from router: icmp_seq=532 ttl=255 time=134.255 ms 64 bytes from router: icmp_seq=533 ttl=255 time=55.565 ms 64 bytes from router: icmp_seq=534 ttl=255 time=36.819 ms 64 bytes from router: icmp_seq=535 ttl=255 time=0.316 ms 64 bytes from router: icmp_seq=536 ttl=255 time=0.292 ms 64 bytes from router: icmp_seq=537 ttl=255 time=0.320 ms 64 bytes from router: icmp_seq=538 ttl=255 time=0.302 ms Sacha
