Re: [dev] [st] Exit upon attempting to render glyph
I use emojis on my dwm bar, and it is convenient on a laptop. While main fonts are occasionally changed, Noto Emoji is always a fallback font for the symbols. I've never had dwm or st crashed, no matter the reason. As it was previously stated by Laslo and Hiltjo, 99.9899735856% of issues are associated with libraries like fontconfig. -- caóc
Re: [dev] [st] Exit upon attempting to render glyph
I like that you guys punish people for stupid shit like emojis, hahaha. fuck emojis. first good feature on suckless in a while :)
Re: [dev] [st] Exit upon attempting to render glyph
On Wed, Aug 09, 2017 at 11:06:28AM -0700, David Lamkins wrote: > The NotoColorEmoji font seems to be the trigger. I can avoid the st > rendering exit by blacklisting that font: This sounds rather similar to the dwm issue discussed in another recent thread -- dwm exiting when rendering emojis with Noto. P signature.asc Description: PGP signature
Re: [dev] [st] Exit upon attempting to render glyph
The NotoColorEmoji font seems to be the trigger. I can avoid the st rendering exit by blacklisting that font: file ~/.config/fontconfig/fonts.conf: Noto Color Emoji By so doing, st renders an empty box for the offending code point. This is the same behavior exhibited by the Unicode variants of xterm and rxvt; the difference is that they work OK without disabling the NotoColorEmoji font. On Wed, Aug 9, 2017 at 10:33 AM, David Lamkins wrote: > I also specified different fonts on the command line, using an st > built with the default config.def.h. For example: ./st -f > DejaVuSansMono . > > Same outcome. > > On Wed, Aug 9, 2017 at 10:19 AM, David Lamkins wrote: >> With default config *except for* font, which is: >> >> char font[] = "NotoMono-17:antialias=true:autohint=false:hintstyle=hintnone"; >> >> Compiled with CFLAGS="-ggdb -O0", >> >> Here's the backtrace. (No change): >> >> #0 __GI__exit (status=status@entry=1) at >> ../sysdeps/unix/sysv/linux/_exit.c:27 >> #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, >> listp=, run_list_atexit=run_list_atexit@entry=true, >> run_dtors=run_dtors@entry=true) at exit.c:98 >> #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 >> #3 0x775caca8 in _XDefaultError (dpy=, >> event=) >> at XlibInt.c:1385 >> #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, >> rep=rep@entry=0x6df620) >> at XlibInt.c:1434 >> #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df620, >> in_XReply=) at xcb_io.c:199 >> #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, >> response=0x6df620, >> in_XReply=in_XReply@entry=0) at xcb_io.c:311 >> #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) >> at xcb_io.c:350 >> #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 >> #9 0x0040e8a4 in run () at x.c:1675 >> #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 >> >> >> On Wed, Aug 9, 2017 at 9:49 AM, David Lamkins wrote: >>> st output upon exit: >>> >>> X Error of failed request: BadLength (poly request too large or >>> internal Xlib length error) >>> Major opcode of failed request: 138 (RENDER) >>> Minor opcode of failed request: 20 (RenderAddGlyphs) >>> Serial number of failed request: 1408 >>> Current serial number in output stream: 1582 >>> >>> >>> I had to break on _exit() in gdb. WIthout that, the response to (gdb) >>> bt is "No stack". >>> >>> Here's the backtrace. (This is with all of my config changes. I'll >>> pare that down and post the results, shortly.) >>> >>> #0 __GI__exit (status=status@entry=1) at >>> ../sysdeps/unix/sysv/linux/_exit.c:27 >>> #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, >>> listp=, run_list_atexit=run_list_atexit@entry=true, >>> run_dtors=run_dtors@entry=true) at exit.c:98 >>> #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 >>> #3 0x775caca8 in _XDefaultError (dpy=, >>> event=) >>> at XlibInt.c:1385 >>> #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, >>> rep=rep@entry=0x6df5b0) >>> at XlibInt.c:1434 >>> #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df5b0, >>> in_XReply=) at xcb_io.c:199 >>> #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, >>> response=0x6df5b0, >>> in_XReply=in_XReply@entry=0) at xcb_io.c:311 >>> #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=>> out>) >>> at xcb_io.c:350 >>> #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 >>> #9 0x0040e8a4 in run () at x.c:1675 >>> #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 >>> >>> On Wed, Aug 9, 2017 at 9:24 AM, Alex Pilon wrote: On Wed, Aug 09, 2017 at 08:36:49AM -0700, David B. Lamkins wrote: > Upon attempting to render Unicode 1f596, st exits. I have the same problem, but with a different input, that I haven't identified yet. However... > See attached strace excerpt. I'd recommend getting the Xlib stderr by running st from another st, so that we can read the message that's obviously being printed out below, and anything else of use, if any. > write(2, "X Error of failed request: BadL"..., 95) = 95 > write(2, "Major opcode of failed request: "..., 36) = 36 > write(2, " (RENDER)\n", 10) = 10 > write(2, " ", 2) = 2 > write(2, "Minor opcode of failed request: "..., 35) = 35 > write(2, " (RenderAddGlyphs)", 18) = 18 > write(2, "\n", 1) = 1 > write(2, " ", 2) = 2 > write(2, "Serial number of failed request:"..., 38) = 38 > write(2, "\n ", 3) = 3 > write(2, "Current serial number in output "..., 45) = 45 > write(2, "\n", 1) = 1
Re: [dev] [st] Exit upon attempting to render glyph
I also specified different fonts on the command line, using an st built with the default config.def.h. For example: ./st -f DejaVuSansMono . Same outcome. On Wed, Aug 9, 2017 at 10:19 AM, David Lamkins wrote: > With default config *except for* font, which is: > > char font[] = "NotoMono-17:antialias=true:autohint=false:hintstyle=hintnone"; > > Compiled with CFLAGS="-ggdb -O0", > > Here's the backtrace. (No change): > > #0 __GI__exit (status=status@entry=1) at > ../sysdeps/unix/sysv/linux/_exit.c:27 > #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, > listp=, run_list_atexit=run_list_atexit@entry=true, > run_dtors=run_dtors@entry=true) at exit.c:98 > #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 > #3 0x775caca8 in _XDefaultError (dpy=, > event=) > at XlibInt.c:1385 > #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, > rep=rep@entry=0x6df620) > at XlibInt.c:1434 > #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df620, > in_XReply=) at xcb_io.c:199 > #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, > response=0x6df620, > in_XReply=in_XReply@entry=0) at xcb_io.c:311 > #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) > at xcb_io.c:350 > #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 > #9 0x0040e8a4 in run () at x.c:1675 > #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 > > > On Wed, Aug 9, 2017 at 9:49 AM, David Lamkins wrote: >> st output upon exit: >> >> X Error of failed request: BadLength (poly request too large or >> internal Xlib length error) >> Major opcode of failed request: 138 (RENDER) >> Minor opcode of failed request: 20 (RenderAddGlyphs) >> Serial number of failed request: 1408 >> Current serial number in output stream: 1582 >> >> >> I had to break on _exit() in gdb. WIthout that, the response to (gdb) >> bt is "No stack". >> >> Here's the backtrace. (This is with all of my config changes. I'll >> pare that down and post the results, shortly.) >> >> #0 __GI__exit (status=status@entry=1) at >> ../sysdeps/unix/sysv/linux/_exit.c:27 >> #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, >> listp=, run_list_atexit=run_list_atexit@entry=true, >> run_dtors=run_dtors@entry=true) at exit.c:98 >> #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 >> #3 0x775caca8 in _XDefaultError (dpy=, >> event=) >> at XlibInt.c:1385 >> #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, >> rep=rep@entry=0x6df5b0) >> at XlibInt.c:1434 >> #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df5b0, >> in_XReply=) at xcb_io.c:199 >> #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, >> response=0x6df5b0, >> in_XReply=in_XReply@entry=0) at xcb_io.c:311 >> #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) >> at xcb_io.c:350 >> #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 >> #9 0x0040e8a4 in run () at x.c:1675 >> #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 >> >> On Wed, Aug 9, 2017 at 9:24 AM, Alex Pilon wrote: >>> On Wed, Aug 09, 2017 at 08:36:49AM -0700, David B. Lamkins wrote: Upon attempting to render Unicode 1f596, st exits. >>> >>> I have the same problem, but with a different input, that I haven't >>> identified yet. However... >>> See attached strace excerpt. >>> >>> I'd recommend getting the Xlib stderr by running st from another >>> st, so that we can read the message that's obviously being printed out >>> below, and anything else of use, if any. >>> write(2, "X Error of failed request: BadL"..., 95) = 95 write(2, "Major opcode of failed request: "..., 36) = 36 write(2, " (RENDER)\n", 10) = 10 write(2, " ", 2) = 2 write(2, "Minor opcode of failed request: "..., 35) = 35 write(2, " (RenderAddGlyphs)", 18) = 18 write(2, "\n", 1) = 1 write(2, " ", 2) = 2 write(2, "Serial number of failed request:"..., 38) = 38 write(2, "\n ", 3) = 3 write(2, "Current serial number in output "..., 45) = 45 write(2, "\n", 1) = 1 >>> >>> I'd also suggest compiling with -g, and getting a backtrace with >>> gdb. Something like this roughly: >>> >>> $ gdb ./st >>> (gdb) start >>> (gdb) continue >>> [trigger the crash] >>> (gdb) bt >>> [copy-paste the backtrace below] >>> >>> Regards, >>> >>> Alex Pilon >> >> >> >> -- >> "I think as musicians, we have more vision than we credit ourselves >> for. We should dive into it without reserve, and take the sort of >> risks it takes to be divisive and impactful. Things have yet to be >> done." >>Aaron Fowler Clark >> >> "Do not seek to follow in the footsteps of the masters. Seek what they >> sought
Re: [dev] [st] Exit upon attempting to render glyph
With default config *except for* font, which is: char font[] = "NotoMono-17:antialias=true:autohint=false:hintstyle=hintnone"; Compiled with CFLAGS="-ggdb -O0", Here's the backtrace. (No change): #0 __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27 #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, listp=, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:98 #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 #3 0x775caca8 in _XDefaultError (dpy=, event=) at XlibInt.c:1385 #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, rep=rep@entry=0x6df620) at XlibInt.c:1434 #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df620, in_XReply=) at xcb_io.c:199 #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, response=0x6df620, in_XReply=in_XReply@entry=0) at xcb_io.c:311 #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) at xcb_io.c:350 #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 #9 0x0040e8a4 in run () at x.c:1675 #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 On Wed, Aug 9, 2017 at 9:49 AM, David Lamkins wrote: > st output upon exit: > > X Error of failed request: BadLength (poly request too large or > internal Xlib length error) > Major opcode of failed request: 138 (RENDER) > Minor opcode of failed request: 20 (RenderAddGlyphs) > Serial number of failed request: 1408 > Current serial number in output stream: 1582 > > > I had to break on _exit() in gdb. WIthout that, the response to (gdb) > bt is "No stack". > > Here's the backtrace. (This is with all of my config changes. I'll > pare that down and post the results, shortly.) > > #0 __GI__exit (status=status@entry=1) at > ../sysdeps/unix/sysv/linux/_exit.c:27 > #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, > listp=, run_list_atexit=run_list_atexit@entry=true, > run_dtors=run_dtors@entry=true) at exit.c:98 > #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 > #3 0x775caca8 in _XDefaultError (dpy=, > event=) > at XlibInt.c:1385 > #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, > rep=rep@entry=0x6df5b0) > at XlibInt.c:1434 > #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df5b0, > in_XReply=) at xcb_io.c:199 > #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, > response=0x6df5b0, > in_XReply=in_XReply@entry=0) at xcb_io.c:311 > #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) > at xcb_io.c:350 > #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 > #9 0x0040e8a4 in run () at x.c:1675 > #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 > > On Wed, Aug 9, 2017 at 9:24 AM, Alex Pilon wrote: >> On Wed, Aug 09, 2017 at 08:36:49AM -0700, David B. Lamkins wrote: >>> Upon attempting to render Unicode 1f596, st exits. >> >> I have the same problem, but with a different input, that I haven't >> identified yet. However... >> >>> See attached strace excerpt. >> >> I'd recommend getting the Xlib stderr by running st from another >> st, so that we can read the message that's obviously being printed out >> below, and anything else of use, if any. >> >>> write(2, "X Error of failed request: BadL"..., 95) = 95 >>> write(2, "Major opcode of failed request: "..., 36) = 36 >>> write(2, " (RENDER)\n", 10) = 10 >>> write(2, " ", 2) = 2 >>> write(2, "Minor opcode of failed request: "..., 35) = 35 >>> write(2, " (RenderAddGlyphs)", 18) = 18 >>> write(2, "\n", 1) = 1 >>> write(2, " ", 2) = 2 >>> write(2, "Serial number of failed request:"..., 38) = 38 >>> write(2, "\n ", 3) = 3 >>> write(2, "Current serial number in output "..., 45) = 45 >>> write(2, "\n", 1) = 1 >> >> I'd also suggest compiling with -g, and getting a backtrace with >> gdb. Something like this roughly: >> >> $ gdb ./st >> (gdb) start >> (gdb) continue >> [trigger the crash] >> (gdb) bt >> [copy-paste the backtrace below] >> >> Regards, >> >> Alex Pilon > > > > -- > "I think as musicians, we have more vision than we credit ourselves > for. We should dive into it without reserve, and take the sort of > risks it takes to be divisive and impactful. Things have yet to be > done." >Aaron Fowler Clark > > "Do not seek to follow in the footsteps of the masters. Seek what they > sought." >Matsuo Basho > > "Knowledge speaks; wisdom listens." >Jimi Hendrix > > http://soundcloud.com/davidlamkins > http://reverbnation.com/lamkins > http://reverbnation.com/lcw > http://lamkins-guitar.com/ > http://lamkins.net/ > http://successful-lisp.com/ -- "I think as musicians, we have more vision than we credit ourselves for. We should dive into
Re: [dev] [st] Exit upon attempting to render glyph
st output upon exit: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 138 (RENDER) Minor opcode of failed request: 20 (RenderAddGlyphs) Serial number of failed request: 1408 Current serial number in output stream: 1582 I had to break on _exit() in gdb. WIthout that, the response to (gdb) bt is "No stack". Here's the backtrace. (This is with all of my config changes. I'll pare that down and post the results, shortly.) #0 __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27 #1 0x768f3383 in __run_exit_handlers (status=status@entry=1, listp=, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:98 #2 0x768f342a in __GI_exit (status=status@entry=1) at exit.c:105 #3 0x775caca8 in _XDefaultError (dpy=, event=) at XlibInt.c:1385 #4 0x775caddd in _XError (dpy=dpy@entry=0x639310, rep=rep@entry=0x6df5b0) at XlibInt.c:1434 #5 0x775c7d07 in handle_error (dpy=0x639310, err=0x6df5b0, in_XReply=) at xcb_io.c:199 #6 0x775c7dc5 in handle_response (dpy=dpy@entry=0x639310, response=0x6df5b0, in_XReply=in_XReply@entry=0) at xcb_io.c:311 #7 0x775c86c5 in _XEventsQueued (dpy=0x639310, mode=) at xcb_io.c:350 #8 0x775aa13a in XFlush (dpy=0x639310) at Flush.c:39 #9 0x0040e8a4 in run () at x.c:1675 #10 0x0040f378 in main (argc=0, argv=0x7fff7c90) at x.c:1764 On Wed, Aug 9, 2017 at 9:24 AM, Alex Pilon wrote: > On Wed, Aug 09, 2017 at 08:36:49AM -0700, David B. Lamkins wrote: >> Upon attempting to render Unicode 1f596, st exits. > > I have the same problem, but with a different input, that I haven't > identified yet. However... > >> See attached strace excerpt. > > I'd recommend getting the Xlib stderr by running st from another > st, so that we can read the message that's obviously being printed out > below, and anything else of use, if any. > >> write(2, "X Error of failed request: BadL"..., 95) = 95 >> write(2, "Major opcode of failed request: "..., 36) = 36 >> write(2, " (RENDER)\n", 10) = 10 >> write(2, " ", 2) = 2 >> write(2, "Minor opcode of failed request: "..., 35) = 35 >> write(2, " (RenderAddGlyphs)", 18) = 18 >> write(2, "\n", 1) = 1 >> write(2, " ", 2) = 2 >> write(2, "Serial number of failed request:"..., 38) = 38 >> write(2, "\n ", 3) = 3 >> write(2, "Current serial number in output "..., 45) = 45 >> write(2, "\n", 1) = 1 > > I'd also suggest compiling with -g, and getting a backtrace with > gdb. Something like this roughly: > > $ gdb ./st > (gdb) start > (gdb) continue > [trigger the crash] > (gdb) bt > [copy-paste the backtrace below] > > Regards, > > Alex Pilon -- "I think as musicians, we have more vision than we credit ourselves for. We should dive into it without reserve, and take the sort of risks it takes to be divisive and impactful. Things have yet to be done." Aaron Fowler Clark "Do not seek to follow in the footsteps of the masters. Seek what they sought." Matsuo Basho "Knowledge speaks; wisdom listens." Jimi Hendrix http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
Re: [dev] [st] Exit upon attempting to render glyph
On Wed, Aug 09, 2017 at 09:37:07AM -0700, David Lamkins wrote: > Compiling with the default config resolves the issue. (OTOH, I can't > use the default font...) > > I've attached a diff of my config.def.h . Can you do it piecemeal with the changes from the diff, especially the font (heck, do it from the command line). But please, share a backtrace. Cheers, Alex Pilon P.S. Apologies for the broken threading/In-Reply-To before. NeoMutt c6b71abc (Fix empty In-Reply-To generation) signature.asc Description: PGP signature
Re: [dev] [st] Exit upon attempting to render glyph
Compiling with the default config resolves the issue. (OTOH, I can't
use the default font...)
I've attached a diff of my config.def.h .
On Wed, Aug 9, 2017 at 8:55 AM, Antenore Gatta wrote:
> On Wed, 9 Aug 2017 08:36:49 -0700
> "David B. Lamkins" wrote:
>
>> \xf0\x9f\x96\x96\n
>
> I cannot reproduce it, which font are you using?
>
> Can you try to compile st with the default config.h and no patches?
>
> --
> -BEGIN GEEK CODE BLOCK-
> Version: 3.12
> GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w---
> O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++
> G e+ h r+++ y
> --END GEEK CODE BLOCK--
>
--
"I think as musicians, we have more vision than we credit ourselves
for. We should dive into it without reserve, and take the sort of
risks it takes to be divisive and impactful. Things have yet to be
done."
Aaron Fowler Clark
"Do not seek to follow in the footsteps of the masters. Seek what they sought."
Matsuo Basho
"Knowledge speaks; wisdom listens."
Jimi Hendrix
http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/
diff --git a/config.def.h b/config.def.h
index 877afab..c391e2a 100644
--- a/config.def.h
+++ b/config.def.h
@@ -5,7 +5,7 @@
*
* font: see http://freedesktop.org/software/fontconfig/fontconfig-user.html
*/
-char font[] = "Liberation Mono:pixelsize=12:antialias=true:autohint=true";
+char font[] = "NotoMono-17:antialias=true:autohint=false:hintstyle=hintnone";
int borderpx = 2;
/*
@@ -54,13 +54,13 @@ unsigned int blinktimeout = 800;
/*
* thickness of underline and bar cursors
*/
-unsigned int cursorthickness = 2;
+unsigned int cursorthickness = 4;
/*
* bell volume. It must be a value between -100 and 100. Use 0 for disabling
* it
*/
-static int bellvolume = 0;
+static int bellvolume = 50;
/* default TERM value */
char termname[] = "st-256color";
@@ -89,7 +89,7 @@ const char *colorname[] = {
"red3",
"green3",
"yellow3",
- "blue2",
+ "steelblue3",
"magenta3",
"cyan3",
"gray90",
@@ -99,7 +99,7 @@ const char *colorname[] = {
"red",
"green",
"yellow",
- "#5c5cff",
+ "steelblue1",
"magenta",
"cyan",
"white",
@@ -128,7 +128,7 @@ unsigned int defaultrcs = 257;
* 6: Bar ("|")
* 7: Snowman ("☃")
*/
-unsigned int cursorshape = 2;
+unsigned int cursorshape = 4;
/*
* Default columns and rows numbers
Re: [dev] [st] Exit upon attempting to render glyph
On Wed, Aug 09, 2017 at 08:36:49AM -0700, David B. Lamkins wrote: > Upon attempting to render Unicode 1f596, st exits. I have the same problem, but with a different input, that I haven't identified yet. However... > See attached strace excerpt. I'd recommend getting the Xlib stderr by running st from another st, so that we can read the message that's obviously being printed out below, and anything else of use, if any. > write(2, "X Error of failed request: BadL"..., 95) = 95 > write(2, "Major opcode of failed request: "..., 36) = 36 > write(2, " (RENDER)\n", 10) = 10 > write(2, " ", 2) = 2 > write(2, "Minor opcode of failed request: "..., 35) = 35 > write(2, " (RenderAddGlyphs)", 18) = 18 > write(2, "\n", 1) = 1 > write(2, " ", 2) = 2 > write(2, "Serial number of failed request:"..., 38) = 38 > write(2, "\n ", 3) = 3 > write(2, "Current serial number in output "..., 45) = 45 > write(2, "\n", 1) = 1 I'd also suggest compiling with -g, and getting a backtrace with gdb. Something like this roughly: $ gdb ./st (gdb) start (gdb) continue [trigger the crash] (gdb) bt [copy-paste the backtrace below] Regards, Alex Pilon signature.asc Description: PGP signature
Re: [dev] [st] Exit upon attempting to render glyph
On Wed, 9 Aug 2017 08:36:49 -0700 "David B. Lamkins" wrote: > \xf0\x9f\x96\x96\n I cannot reproduce it, which font are you using? Can you try to compile st with the default config.h and no patches? -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w--- O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++ G e+ h r+++ y --END GEEK CODE BLOCK--
