Hello,
Thank you for the replies.
As a few of you have pointed out, I completely forgot version information. Oops.
I'm running the latest tip of master (7f990328e4fec8dfaaad311cb8af2304b58c872e) with the default configuration.
It doesn't seem to be triggering a core dump. In fact it's exiting with a code of 1, not 139, so it's definitely not segfaulting. I did check my ulimits and /proc/sys/kernel/core_pattern just to make sure something funny isn't going on. Intentionally triggering a segfault with a custom little program does produce a core dump as expected.
With that in mind, it occurred to me to put a breakpoint on _exit to see who is killing st. Here is a backtrace for that:
#0 __GI__exit (status=status_AT_entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1 0x00007ffff68ef673 in __run_exit_handlers (status=1, listp=<optimized out>,
run_list_atexit=run_list_atexit_AT_entry=true, run_dtors=run_dtors_AT_entry=true) at exit.c:98
#2 0x00007ffff68ef71a in __GI_exit (status=<optimized out>) at exit.c:105
#3 0x00007ffff75c2ca8 in _XDefaultError () from /usr/lib/libX11.so.6
#4 0x00007ffff75c2ddd in _XError () from /usr/lib/libX11.so.6
#5 0x00007ffff75bfd07 in ?? () from /usr/lib/libX11.so.6
#6 0x00007ffff75bfdc5 in ?? () from /usr/lib/libX11.so.6
#7 0x00007ffff75c06c5 in _XEventsQueued () from /usr/lib/libX11.so.6
#8 0x00007ffff75b2397 in XPending () from /usr/lib/libX11.so.6
#9 0x000000000040abb0 in run ()
#10 0x000000000040af19 in main ()
So indeed, we seem to be getting a clean exit somewhere in libX11 due to an unhandled error. I'm not sure how to get something more useful though. It's curious that some of you seem to be getting the tofu symbol just fine. Maybe the issue involves something else in the software stack as well. For the sake of thoroughness, here are the versions of linked libraries I'm running:
bzip2-1.0.6
expat-2.2.2
fontconfig-2.12.4
freetype-2.8
glibc-2.25
libX11-1.6.5
libXau-1.0.8
libXdmcp-1.1.2
libXft-2.3.2
libXrender-0.9.10
libpng-1.6.30
libxcb-1.12
zlib-1.2.11
Cheers,
On Fri, Jul 28, 2017 at 08:34:25AM +0200, Silvan Jegen wrote:
> Hi
>
> On Fri, Jul 28, 2017 at 7:44 AM, B. Wilson <x_AT_wilsonb.com> wrote:
> > The character in question was U+1F917. I was able to reproduce the crash in st by cat-ing a file containing the single bad character. Pasting it from the X clipboard also reliably causes the crash.
> >
> > This is the error that is produced:
> >
> > X Error of failed request: BadLength (poly request too large or internal Xlib length error)
> > Major opcode of failed request: 139 (RENDER)
> > Minor opcode of failed request: 20 (RenderAddGlyphs)
> > Serial number of failed request: 1442
> > Current serial number in output stream: 1454
> >
> > I'm guessing that somewhere a 'missing glyph' error isn't getting checked, but I wasn't able to find the relevant code from a quick perusal.
>
> In that case I would expect st to crash if I paste the character into
> it. Instead I get the following:
>
> $ echo 🤗 | xxd
> 00000000: f09f a497 0a
>
> so st just shows me a placeholder character (tofu) and no crash occurs.
>
> Which version of st are you using? I am at git tip
> 7f990328e4fec8dfaaad311cb8af2304b58c872e .
>
--
ウィルソン ブランドン
早稲田大学基幹理工学研究科応用数学専攻
Brandon M. Wilson
Waseda University
School of Fundamental Science and Engineering
Department of Applied Mathematics
Received on Fri Jul 28 2017 - 12:28:44 CEST