PDF generation hangs

[fefe]

Upgraded to 1.0.3 / 2018-04-30

When saving markdown to pdf, a <filename>_tmp.html file is created but that is all. Puppeteer is installed successfully and in the Task Manager I see 7 Chromium processes, but they are just hanging and the process is never completed. There are no error messages or any feedback.

[fefe]

Narrowed it down to external links, this is what it has problem with: ` 

<div><img src="https://lorempixel.com/400/200/"></div> ` Images referencing to local files work with both syntax.

[yzane]

@fefe

I tried it and there was no problem with the external link.

![lorempixel](https://lorempixel.com/400/200/ "lorempixel")

<div><img src="https://lorempixel.com/400/200/"></div>

test.pdf

Please try the markdown-pdf.executablePath option.

[fefe]

Is there anything I can do to debug this further?

I can reliably replicate the issue, if I put any of the above lines in an .md file, the process hangs after creating the _tmp.html file and I can see the 7 chromium processes spawning and never closing.

Without these lines in the .md file, it takes about 1 second to generate the pdf.

[fefe]

I have tested with providing the executable path to the installed Chrome. Google Chrome Version 66.0.3359.139 (Official Build) (64-bit) The same thing happens, a bunch of Chrome processes are fired up, but they don't complete, and the _tmp.html file just stays there.

[yzane]

@fefe I improved Exception handling with markdown-pdf ver1.0.5. Is any error message displayed?

[FelixDz]

I get a similar issue but for any PDF generation, even only with a title (no special markup, no images...). I'm on Archlinux.

With no special configuration, I get the following errors :

TypeError: Cannot read property 'newPage' of undefined

ERROR: exportPdf()

Error: Failed to launch chrome!
[0529/153654.720592:FATAL:zygote_host_impl_linux.cc(124)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x55de89419b0c base::debug::StackTrace::StackTrace()
#1 0x55de89432780 logging::LogMessage::~LogMessage()
#2 0x55de884c22b1 content::ZygoteHostImpl::Init()
#3 0x55de88134c65 content::BrowserMainLoop::EarlyInitialization()
#4 0x55de8813aa69 content::BrowserMainRunnerImpl::Initialize()
#5 0x55de8d2649a8 headless::HeadlessContentMainDelegate::RunProcess()
#6 0x55de89154a00 content::RunNamedProcessTypeMain()
#7 0x55de891552e8 content::ContentMainRunnerImpl::Run()
#8 0x55de8915ef24 service_manager::Main()
#9 0x55de89153f14 content::ContentMain()
#10 0x55de8d2639b9 headless::(anonymous namespace)::RunContentMain()
#11 0x55de8d263a42 headless::HeadlessBrowserMain()
#12 0x55de8915bf9d headless::HeadlessShellMain()
#13 0x55de877ba1ac ChromeMain
#14 0x7fad2624d06b __libc_start_main
#15 0x55de877ba02a _start

Received signal 6
#0 0x55de89419b0c base::debug::StackTrace::StackTrace()
#1 0x55de89419671 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7fad2c226a80 <unknown>
#3 0x7fad2626086b __GI_raise
#4 0x7fad2624b40e __GI_abort
#5 0x55de89418105 base::debug::BreakDebugger()
#6 0x55de89432bca logging::LogMessage::~LogMessage()
#7 0x55de884c22b1 content::ZygoteHostImpl::Init()
#8 0x55de88134c65 content::BrowserMainLoop::EarlyInitialization()
#9 0x55de8813aa69 content::BrowserMainRunnerImpl::Initialize()
#10 0x55de8d2649a8 headless::HeadlessContentMainDelegate::RunProcess()
#11 0x55de89154a00 content::RunNamedProcessTypeMain()
#12 0x55de891552e8 content::ContentMainRunnerImpl::Run()
#13 0x55de8915ef24 service_manager::Main()
#14 0x55de89153f14 content::ContentMain()
#15 0x55de8d2639b9 headless::(anonymous namespace)::RunContentMain()
#16 0x55de8d263a42 headless::HeadlessBrowserMain()
#17 0x55de8915bf9d headless::HeadlessShellMain()
#18 0x55de877ba1ac ChromeMain
#19 0x7fad2624d06b __libc_start_main
#20 0x55de877ba02a _start
  r8: 0000000000000000  r9: 00007ffe61aad190 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007ffe61aad898 r13: 0000000000000161 r14: 00007ffe61aad8a0 r15: 00007ffe61aad439
  di: 0000000000000002  si: 00007ffe61aad190  bp: 00007ffe61aad3e0  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007fad2626086b  sp: 00007ffe61aad190
  ip: 00007fad2626086b efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

Using the markdown-pdf.executablePath option to set the executable to /usr/bin/google-chrome-stable, no errors show up but no PDF is generated, I only have a ***_tmp.html file near my markdown file.

[Toub]

Same problem here.

Using my local chromium fixed it:

    "markdown-pdf.executablePath": "/usr/bin/chromium",

OS debian stretch Chromium version: 66.0.3359.117-1~deb9u1 amd64

[FelixDz]

@Toub Was about to say the same, using the local chromium fixed it.

[Caedendi]

Sorry for necroposting but I'm running into this same issue today. I'm also a Chromium user but I'm on Windows. Will this workaround work here too? What should I put into the field?