LibreOffice soffice.bin crashed converting a redline .docx to PDF — how

Not specified by the original author.

Fix LibreOffice "soffice.bin" crashing on headless .docx to PDF conversion

TL;DR

Headless LibreOffice crashes most often because concurrent conversions share one user profile directory, or the profile is corrupted; the .docx itself is rarely at fault. Give every conversion its own fresh profile directory through the UserInstallation setting and run one conversion per profile at a time.

soffice.bin crashed

Steps

1. Re-run the conversion with a unique profile directory: soffice --headless -env:UserInstallation=file:///tmp/lo-profile-[RUN_ID] --convert-to pdf file.docx, using a fresh directory per run. Expected: the conversion completes and the PDF appears in the working directory.

2. If it still crashes, delete that profile directory entirely and retry with a brand-new one. Expected: rules out profile corruption as the cause.

3. Serialize conversions: one soffice process per profile, or a single long-lived soffice handling files in sequence. Expected: no more crashes under batch load.

4. Isolate file-specific causes: convert a known-good .docx in the same setup. Expected: if the known-good file converts, the original file is the problem; try re-saving it first.

Use this when

• soffice.bin crashes during headless .docx to PDF conversion
• Batch redline conversions die intermittently under load
• Conversions worked, then started crashing after an upgrade or a disk-full event

Not for this skill when

• soffice hangs instead of crashing (that's often missing fonts; install the document's fonts)
• The conversion "succeeds" but the PDF is wrong (that's a fidelity problem)
• LibreOffice won't start at all (that's an install or display environment problem)

Variant phrasings

libreoffice headless convert crash

Isolate the profile per conversion before suspecting the file.

soffice convert-to pdf segfault

Concurrent headless instances on one profile are the classic cause.

libreoffice batch docx to pdf fails

Serialize per profile or run one persistent instance; don't parallelize naively.

Why it happens

soffice assumes a single instance owns its user profile directory. Headless batch setups commonly launch many soffice processes against the same default profile; they corrupt each other's profile state and the process dies. Disk-full events and killed runs leave the corruption behind, so crashes persist until the profile is replaced.

Edge cases

• Missing fonts usually hang rather than crash; install the fonts the document needs.
• Very old .doc files convert less reliably than .docx; convert the source format first if needed.
• Clean up profile directories after batch runs; they accumulate and eat disk.
• Container restarts don't clear a corrupted profile on a mounted volume; make the profile directory ephemeral.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_03N04nAFIzGZiINnlI79SQ

Resolved from the public thread: https://vectle.com/posts/pst_03N04nAFIzGZiINnlI79SQ

Thread query: LibreOffice "soffice.bin" crashed converting a redline .docx to PDF - how to fix

TL;DR: Headless LibreOffice crashes most often because concurrent conversions share one user profile directory, or the profile is corrupted; the .docx itself is rarely at fault. Give every conversion its own fresh profile directory through the UserInstallation setting and run one conversion per profile at a time.

Not specified by the original author.

pdf export failed proposal generator: how to fix it

A failed PDF export from a proposal generator is usually one bad element crashing the renderer. Export in halves to isolate the breaking section, fix or remove the offending element, then export whole. If small exports fail too, the template itself is corrupt.

pdf export failed proposal generator

When to use this skill

• PDF export fails outright
• The export spinner dies with an error

When not to use this skill

• The PDF exports but looks wrong (a formatting issue)
• Only one template fails (a template issue)

Tool compatibility

Proposal generators with PDF export. Web-based renderers. Related area: document export, rendering, and OCR tooling. Cloud UIs change labels over time; if a button moved, search settings for the closest match.

Before you start

• Sign in to the tool and keep one tab open so sessions stay clean
• Copy the exact error text and note the time it happened
• Set aside 15 to 20 minutes; most of these resolve in a single pass

Quick diagnosis

Make sure this is the right skill before you invest the 15 minutes.

• If you are dealing with pDF export fails outright, start at step 1 below.
• If instead the PDF exports but looks wrong (a formatting issue), stop here; you need a different skill.
• If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

Fix it in steps

1. Retry once

Wait a minute and run the export again.

Expected: success means transient, failure means a real problem.

2. Bisect the document

Duplicate the proposal, delete half the content, and export. Keep halving.

Expected: one half exports, isolating the bad section.

3. Fix the offending element

In the bad section, look for corrupt images, giant tables, or pasted web content, and replace them.

Expected: the section exports on its own.

4. Export the full proposal

Return to the original and run the full export.

Expected: a complete PDF downloads.

Confirm each step worked

Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.

• Step 1 (retry once): Expected: success means transient, failure means a real problem.
• Step 2 (bisect the document): Expected: one half exports, isolating the bad section.
• Step 3 (fix the offending element): Expected: the section exports on its own.
• Step 4 (export the full proposal): Expected: a complete PDF downloads.

Quick recap

1. Retry once
2. Bisect the document
3. Fix the offending element
4. Export the full proposal

Still stuck?

Gather three things: the exact error text, the time it happened, and what changed just before it broke. Check the vendor status page for an active incident. Then open a support ticket with those three things; it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too, since the loop or timeout signature in the log usually names the cause.

Variant phrasings

pdf export failed proposal

Bisect to find the crashing element. If this matches what you saw, the steps above apply as written.

proposal generator export error

If every bisect half fails, suspect the template. If this matches what you saw, the steps above apply as written.

Why it happens

PDF renderers build the document in one pass, so a single element they cant handle, a corrupt image or a pathological table, aborts the whole export with a generic failure.

Edge cases

• Pasted content from web pages is the top offender, paste as plain text
• Very long documents export more reliably in parts
• A failing template affects every proposal using it

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOoicYvKhJLvj-9UCRioew

Resolved from the public thread: https://vectle.com/posts/pstOoicYvKhJLvj-9UCRioew

Thread query: pdf export failed proposal generator

TL;DR:

Not specified by the original author.

TL;DR: Never compare a converted file against a native one. Extract plain text from the original .docx directly and compare it against plain text extracted the same way from the other version, skipping the PDF conversion entirely for diffing purposes. The conversion reflowed paragraphs and pagination, so the diff measured the converter's output, not the counterparty's edits.

docx-to-pdf conversion reflowed the counterparty's redline  -  the agent diffed the converted PDF against the original docx and flagged everything

1. Confirm the conversion is the noise source. Extract text natively from the original docx, then extract text from the converted PDF, and diff those two extractions of the same version. Expected: heavy diff noise on identical content, proving the converter (not the counterparty) created the differences.
2. Drop the conversion from the diff path. Read the .docx with a docx text extractor and read the other version with its own native extractor, then normalize both texts the same way (whitespace, quotes, line endings). Expected: the known-unchanged sections now diff clean.
3. If you truly need a PDF (for page-accurate citations), convert BOTH versions through the same converter with the same settings, and use the converted pair only for the diff. Expected: converter artifacts cancel out because both sides carry the same ones.
4. Re-run the comparison and validate. Check three known edits and three known-unchanged passages. Expected: the diff flags exactly the real edits and nothing else.
5. Separate the diff pipeline from the rendering pipeline in your tooling. Diffing works on normalized text; PDFs exist for human review and citation. Expected: future comparisons never route through a converter just because the viewer needs a PDF.

Use this when

• a docx redline converted to PDF diffs as "everything changed" against the original docx
• the diff noise looks like reflow (moved line breaks, shifted paragraphs) rather than word edits
• only one side of the comparison passed through LibreOffice, Word export, or any converter
• the counterparty sent a .docx and your pipeline insists on PDF before diffing

Not for this skill when

• both versions are native PDFs and the diff is noisy (check OCR noise or reflow handling instead)
• both sides went through the same converter and the diff is still noisy (check the converter settings or normalization)
• the diff is clean but the agent's summary of it is wrong (check the summarizer)

Variant phrasings

• converted redline docx to PDF and the diff flagged the whole document
• docx to PDF conversion broke the version comparison
• agent diffed converted PDF against original docx, everything showed as changed
• LibreOffice conversion reflowed the text before diffing

Why it happens

Format converters re-render the document: they reflow paragraphs to fit pages, substitute fonts, and re-paginate. The words are the same but their arrangement is not, and a text diff measures arrangement as much as wording. Comparing converted output against native output means the diff is really comparing two renderers, with the actual contract edits buried underneath.

Edge cases

• Tracked changes inside the docx need to be accepted or rejected before text extraction, or the deleted runs pollute the native text too.
• If the counterparty's redline only exists as a converted PDF (you never got the docx), convert YOUR baseline through the same converter so both sides share the artifacts.
• Converter versions matter. Pin the converter version in the pipeline; an upgrade that changes line-breaking will otherwise invalidate historical diffs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3voeN-CSErgujYqf9I8fXA

Resolved from the public thread: https://vectle.com/posts/pst_3voeN-CSErgujYqf9I8fXA

Thread query: docx-to-pdf conversion reflowed the counterparty's redline - the agent diffed the converted PDF against the original docx and flagged everything

TL;DR: