Dear Maintainer,

When running pdfpc, it directly terminates with bad_alloc
==60144== Memcheck, a memory error detector
==60144== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==60144== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==60144== Command: pdfpc slides.pdf
==60144==
--60144-- WARNING: unhandled amd64-linux syscall: 315
--60144-- You may be able to write your own handler.
--60144-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--60144-- Nevertheless we consider this a bug.  Please report
--60144-- it at http://valgrind.org/support/bug_reports.html.
==60144== Warning: set address range perms: large range [0x17700000, 0x57702000) (noaccess)
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
==60144==
==60144== Process terminating with default action of signal 6 (SIGABRT)
==60144==    at 0x92B2CE1: raise (raise.c:51)
==60144==    by 0x929C536: abort (abort.c:79)
==60144==    by 0x9A717EB: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==60144==    by 0x9A7C965: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==60144==    by 0x9A7C9D0: std::terminate() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==60144==    by 0x9A7CC64: __cxa_throw (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==60144==    by 0x9A73F0E: std::__throw_bad_alloc() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==60144==    by 0xB44F53B: WTF::FileSystemImpl::pathByAppendingComponent(WTF::String const&, WTF::String const&) (in /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18.19.6)
==60144==    by 0x5B0DEAE: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.4)
==60144==    by 0x5B0DF3A: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.4)
==60144==    by 0x5AF8BEA: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.4)
==60144==    by 0x5A81540: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.4)
==60144==
==60144== HEAP SUMMARY:
==60144==     in use at exit: 10,223,493 bytes in 56,726 blocks
==60144==   total heap usage: 253,947 allocs, 197,221 frees, 26,862,070 bytes allocated
==60144==
==60144== LEAK SUMMARY:
==60144==    definitely lost: 49,152 bytes in 2 blocks
==60144==    indirectly lost: 0 bytes in 0 blocks
==60144==      possibly lost: 13,516 bytes in 136 blocks
==60144==    still reachable: 9,850,097 bytes in 54,444 blocks
==60144==                       of which reachable via heuristic:
==60144==                         length64           : 8,528 bytes in 131 blocks
==60144==                         newarray           : 6,920 bytes in 72 blocks
==60144==         suppressed: 0 bytes in 0 blocks
==60144== Rerun with --leak-check=full to see details of leaked memory
==60144==
==60144== For lists of detected and suppressed errors, rerun with: -s
==60144== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Thanks for the bug report.

I'm unable to replicate this with some other PDF file using version 4.5.0-3.

Could I trouble you to upgrade to the version in testing and see if it
still happens?
And if so, I need details: a particular PDF file it does this on, and
also info about the environment: Gnome with Wayland, or whatever.