tonhowtf/omniget · critical
nao criou o documento
Error message
nao criou o documento
What it means
The FFI call to the PDF engine's document-creation function returned a null pointer, so no PDF document object could be allocated. The library wraps the raw C API (api.new_doc) and treats any null handle as a fatal allocation/initialization failure, raising this anyhow error.
Solutions
- Check available memory in the environment and raise limits (ulimit, container memory) before retrying
- Verify the native PDF library is loaded correctly and matches the expected ABI/version
- Retry the operation once; a transient allocation failure may succeed later
- If it persists, log the environment details and report — this indicates a broken native setup
Example fix
// before
let doc = Document::new();
// after
match Document::new() {
Ok(doc) => doc,
Err(e) => { eprintln!("PDF engine failed to create document: {e}"); return Err(e); }
} Defensive patterns
Strategy: try-catch
Validate before calling
// No pre-call check is reliable; guard the environment instead.
fn can_attempt() -> bool { /* check available memory / lib loaded */ true } Try / catch
match doc_result {
Ok(doc) => use(doc),
Err(e) if e.to_string().contains("nao criou o documento") => {
// native alloc/init failure: free memory, retry once, else abort
}
Err(e) => return Err(e),
} Prevention
- Run in environments with adequate free memory
- Keep the native PDF library binaries in sync with the Rust wrapper version
- Retry once on transient allocation failures before giving up
- Log OS memory stats when this fires to aid diagnosis
When it happens
Trigger: Calling any Document-creating API (e.g. creating a new/empty PDF document) when the underlying native library fails to allocate the document object — typically from memory exhaustion, an unloaded or corrupted native PDF library, or an incompatible/misloaded C API table.
Common situations: Low-memory environments (containers with tight memory limits), the native PDF shared library failing to initialize properly, or bundled binary mismatch after an app update so the vtable points at a broken implementation.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- pagina nao abriu
- sem memoria para x
- nao importou as paginas
- nao gravou o PDF
- o source deste arXiv e um PDF, nao tem LaTeX
AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12).
Data as JSON: /api/errors/55c3da76cc294033.
Report an issue: GitHub.
Appendix: source
Thrown at src-tauri/omniget-core/src/core/tools/pdf.rs:214
3 => "nao e um PDF valido",
4 => "senha incorreta ou ausente",
5 => "esquema de seguranca nao suportado",
6 => "pagina invalida",
_ => "erro desconhecido",
};
return Err(anyhow!("{}: {}", path.display(), why));
}
Ok(Document {
api,
doc,
_data: data,
})
}
fn new(api: &'static Api) -> anyhow::Result<Self> {
let doc = unsafe { (api.new_doc)() };
if doc.is_null() {
return Err(anyhow!("nao criou o documento"));
}
Ok(Document {
api,
doc,
_data: Vec::new(),
})
}
fn pages(&self) -> usize {
unsafe { (self.api.page_count)(self.doc) }.max(0) as usize
}
fn page(&self, index: usize) -> anyhow::Result<PageRef<'_>> {
let page = unsafe { (self.api.load_page)(self.doc, index as c_int) };
if page.is_null() {
return Err(anyhow!("pagina {} nao abriu", index + 1));
}
Ok(PageRef {View on GitHub (pinned to 8600b91f42)