zadam / trilium

Build your personal knowledge base with Trilium Notes
GNU Affero General Public License v3.0
27.2k stars 1.9k forks source link

Segmentation fault (SIGSEGV) when trying to save edited PDF #2205

Closed sigaloid closed 3 years ago

sigaloid commented 3 years ago

When I edit a PDF and click the Download button and save with changes, trilium gives me this error: fish: “trilium” terminated by signal SIGSEGV (Address boundary error) I was going to save it to /tmp/ then click upload new revision. This seems like an internal error with Chromium's PDF handler, though, but if there is something I can do to debug this or get more helpful logs I'm glad to.

Standard 64-bit CPU, 4GB ram, running Lubuntu (LXDE). Can't imagine anything particular about my setup; will try on my desktop when I get home.

sigaloid commented 3 years ago

SIGSEGV on my desktop computer, as well. Simply a PDF with forms, seems to be reproducible on my machines with.

Steps to reproduce: Open PDF inside Trilium. Make edit inside form. Click :arrow_down: and choose save with edits. Watch as Trilium segfaults.

Anyone else like to test? OoPdfFormExample.pdf

abitofevrything commented 3 years ago

Also happens with latest master on Artix Linux, nothing special with my setup either. As you said this is most likely an issue with the chromium PDF viewer.

abitofevrything commented 3 years ago

I'm able to get the following logs out of electron with --enable-logging, meaning this is almost certainly a chromium error.

#0 0x55f2b9aeecf9 (/usr/lib/electron13/electron+0x4703cf8)
  r8: 0000000000000004  r9: 0000000000000000 r10: 0000000000000001 r11: 00007ffeef022fa8
 r12: 00007ffeef023190 r13: 00002566ba6a6000 r14: 0000000000000004 r15: 00007ffeef0230a0
  di: 00002566ba9c8cc0  si: 00007ffeef0231f0  bp: 00007ffeef023090  bx: 00007ffeef023050
  dx: 00007ffeef023190  ax: 0000000000000000  cx: aaaaaaaaaaaaaaaa  sp: 00007ffeef023030
  ip: 000055f2b994ce01 efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
sigaloid commented 3 years ago

Odd, because this works fine in standard Chromium. Seems to be an Electron or Chromium error when being embedded inside Electron. I wonder how to report this upstream, but I don't think this is an obscure error; seems to happen with every editable PDF I've tested.

abitofevrything commented 3 years ago

I couldn't find a bug about segfaults with edited PDFs on chromium's bug tracker, but then I might just not have searched for the right terms.

sigaloid commented 3 years ago

If it's just Trilium that this happens with, then this might be in-scope for this issue (rather than being an upstream issue). I can't find any other applications it crashes with, shall I try reporting it in the Electron repo? I'm not familiar with the particulars with how Trilium handles PDF's, maybe there's a library it uses to open it?

https://github.com/zadam/trilium/blob/f6776df645ae2cb87b588274e88eb9db56193e11/src/public/app/services/note_content_renderer.js#L82-LL84 seems to say it's just an iframe. I wonder if we could get a Windows user to test this, maybe it's handled differently?

In the browser, it handles it just fine in Firefox and Chromium. It's only the desktop version implying it's an Electron issue.

I'll see if I can get some sort of debugging running.

abitofevrything commented 3 years ago

This also happens on Windows 10. (logs below, nothing useful though)

Generated CSRF token GiT2ApX3-RjYVuB4FRzL4rkYtzgmW3SFeHXI with secret undefined
[10964:1010/210309.118:INFO:CONSOLE(13)] "(electron) The remote module is deprecated. Use https://github.com/electron/remote instead.", source: electron/js2c/renderer_init.js (13)
websocket client connected
200 GET /api/options with 6292 bytes took 2ms
200 GET /api/tree with 1893 bytes took 0ms
Keyboard action showNoteInfo found in database, but not in action definition.
Keyboard action showLinkMap found in database, but not in action definition.
Keyboard action focusOnAttributes found in database, but not in action definition.
Keyboard action toggleZenMode found in database, but not in action definition.
Keyboard action toggleRibbonTabLinkMap found in database, but not in action definition.
Slow 200 GET /api/keyboard-actions with 11551 bytes took 10ms
[10964:1010/210309.184:INFO:CONSOLE(198)] "21:03:09 Connected to server ws://127.0.0.1:37740/ with WebSocket", source: http://127.0.0.1:37740/app/services/ws.js (198)
200 GET /api/keyboard-shortcuts-for-notes with 2 bytes took 0ms
200 GET /api/script/widgets with 2 bytes took 1ms
[10964:1010/210309.508:INFO:CONSOLE(80)] "Cannot find action logout", source: http://127.0.0.1:37740/app/services/keyboard_actions.js (80)
[10964:1010/210309.541:INFO:CONSOLE(91)] "Call to initialRenderCompleteEvent in comp-LeftPaneToggleWidget-B6Ayj9WR took 25ms", source: http://127.0.0.1:37740/app/widgets/component.js (91)
[10964:1010/210309.638:INFO:CONSOLE(91)] "Call to newNoteContextCreatedEvent in comp-SplitNoteContainer-6068ADLK took 75ms", source: http://127.0.0.1:37740/app/widgets/component.js (91)
200 POST /api/tree/load with 1456 bytes took 1ms
200 GET /api/search/%23bookmarked%20or%20%23bookmarkFolder with 2 bytes took 1ms
[10964:1010/210311.535:INFO:CONSOLE(91)] "Call to noteSwitchedEvent in comp-ScrollingContainer-ijFH47jD took 26ms", source: http://127.0.0.1:37740/app/widgets/component.js (91)
200 GET /api/notes/7syqzfxKvany with 442 bytes took 9ms
200 GET /api/script/startup with 2 bytes took 2ms
204 PUT /api/options with 0 bytes took 7ms
200 GET /api/notes/HaZNXFmcj5o1 with 438 bytes took 1ms
204 PUT /api/options with 0 bytes took 1ms
200 GET /api/notes/7syqzfxKvany with 442 bytes took 0ms
[6368:1010/210334.143:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is disabled

I'd say that this isn't a Trilium specific problem because Trilium doesn't use any special handlers for PDF previews. If I had to guess, I'd say this was caused by the PDF preview being in an iframe because thats the only real difference from being a standalone page. This might be fixed in electron 15+ but Trilium still uses electron 13 and I'm not sure how to migrate (electron-rebuild nightmares).

zadam commented 3 years ago

My assumption is that editing PDFs is simply not supported in electron. PDF support is relatively recent (IIRC from Electron 8) and it's been quite buggy and incomplete - e.g. annotations never worked but there were still buttons suggesting it's possible. So I assume it's something similar here.

If somebody has time for this then IMHO the best course of action would be to try to reproduce it in https://github.com/electron/electron-quick-start and reporting this in the electron issues.

sigaloid commented 3 years ago

Alas, it's true.

https://user-images.githubusercontent.com/69441971/136713578-13a83c57-5e7b-495c-82fc-2cdf81ffaeb0.mp4

Time to report upstream! Closing for now.

sigaloid commented 3 years ago

This might be fixed in electron 15+ but Trilium still uses electron 13 and I'm not sure how to migrate (electron-rebuild nightmares).

It seems to occur in 15 as well: https://github.com/sigaloid/electron-pdf-crash/blob/main/package.json#L20

sigaloid commented 3 years ago

Reported: https://github.com/electron/electron/issues/31373