Descrição do problema
convert_docx_to_pdf (packtools/sps/formats/pdf/utils/file_utils.py) chama o LibreOffice assim:
subprocess.run([
binary, '--headless', '--convert-to', 'pdf', docx_path, '--outdir', output_dir
], check=True)Sem timeout=. Se o LibreOffice travar convertendo um DOCX específico (soffice.bin preso a ~100% de CPU, sem produzir saída nem terminar sozinho - não é um erro que o LibreOffice reporta, é um travamento de verdade), o processo Python que chamou convert_docx_to_pdf fica bloqueado indefinidamente, sem exceção, sem log, sem forma de perceber o problema a não ser matar o processo manualmente de fora.
Isso é especialmente sério dado que a geração de PDF está planejada para virar um serviço web gratuito e online (ver a diretriz de 5 anos do projeto) - um travamento sem timeout nesse contexto significa uma requisição (ou um worker inteiro) travada para sempre a cada documento com esse problema, sem qualquer forma de recuperação automática.
Passos para reproduzir o problema
Rodando a geração em lote contra um corpus de 593 artigos reais, 5 artigos (0,8%) travaram a conversão DOCX→PDF de forma reproduzível (testado 2-3x cada, inclusive a partir de um perfil limpo do LibreOffice, sem nenhum lock/arquivo temporário residual): ape/v39/1982-0194-ape-39-eAPE000241, bgoeldi/v21n1/1981-8122-bgoeldi-21-1-e20240080, brag/v85/0006-8705-brag-85-e20250128, jped/v102n1/0021-7557-jped-102-01-101471, rac/v30n1/1982-7849-rac-30-01-e240336. Em todos os casos, soffice.bin fica preso a 100% de CPU sem nunca terminar - não identifiquei a causa exata do travamento em si (não parece estar ligado a mesclagem de célula de tabela nem a nenhuma característica óbvia do XML), mas o fato de existirem casos reais que travam já justifica ter um limite de tempo.
Comportamento esperado
convert_docx_to_pdf deveria aceitar um parâmetro de timeout (com um valor padrão razoável), encerrando o processo do LibreOffice e levantando uma exceção clara (em vez de travar para sempre) quando o limite for atingido. Como o LibreOffice roda como um processo lançador (oosplash) que gera um soffice.bin separado, encerrar só o processo direto não é suficiente - os dois precisam ser encerrados (ex. pkill -f <caminho_do_docx>, que casa com ambos pelo argumento de linha de comando, independente de relação de grupo de processos).
Anexos
Achado ao gerar em lote 593 artigos reais do corpus fornecido pela Roberta (layout_roberta/pacote_xml_pdf_csv/).
Função envolvida: convert_docx_to_pdf (packtools/sps/formats/pdf/utils/file_utils.py).
Ambiente utilizado
packtools, gerador de PDF (packtools/sps/formats/pdf/), LibreOffice em modo headless.
Descrição do problema
convert_docx_to_pdf(packtools/sps/formats/pdf/utils/file_utils.py) chama o LibreOffice assim:Sem
timeout=. Se o LibreOffice travar convertendo um DOCX específico (soffice.binpreso a ~100% de CPU, sem produzir saída nem terminar sozinho - não é um erro que o LibreOffice reporta, é um travamento de verdade), o processo Python que chamouconvert_docx_to_pdffica bloqueado indefinidamente, sem exceção, sem log, sem forma de perceber o problema a não ser matar o processo manualmente de fora.Isso é especialmente sério dado que a geração de PDF está planejada para virar um serviço web gratuito e online (ver a diretriz de 5 anos do projeto) - um travamento sem timeout nesse contexto significa uma requisição (ou um worker inteiro) travada para sempre a cada documento com esse problema, sem qualquer forma de recuperação automática.
Passos para reproduzir o problema
Rodando a geração em lote contra um corpus de 593 artigos reais, 5 artigos (0,8%) travaram a conversão DOCX→PDF de forma reproduzível (testado 2-3x cada, inclusive a partir de um perfil limpo do LibreOffice, sem nenhum lock/arquivo temporário residual):
ape/v39/1982-0194-ape-39-eAPE000241,bgoeldi/v21n1/1981-8122-bgoeldi-21-1-e20240080,brag/v85/0006-8705-brag-85-e20250128,jped/v102n1/0021-7557-jped-102-01-101471,rac/v30n1/1982-7849-rac-30-01-e240336. Em todos os casos,soffice.binfica preso a 100% de CPU sem nunca terminar - não identifiquei a causa exata do travamento em si (não parece estar ligado a mesclagem de célula de tabela nem a nenhuma característica óbvia do XML), mas o fato de existirem casos reais que travam já justifica ter um limite de tempo.Comportamento esperado
convert_docx_to_pdfdeveria aceitar um parâmetro de timeout (com um valor padrão razoável), encerrando o processo do LibreOffice e levantando uma exceção clara (em vez de travar para sempre) quando o limite for atingido. Como o LibreOffice roda como um processo lançador (oosplash) que gera umsoffice.binseparado, encerrar só o processo direto não é suficiente - os dois precisam ser encerrados (ex.pkill -f <caminho_do_docx>, que casa com ambos pelo argumento de linha de comando, independente de relação de grupo de processos).Anexos
Achado ao gerar em lote 593 artigos reais do corpus fornecido pela Roberta (
layout_roberta/pacote_xml_pdf_csv/).Função envolvida:
convert_docx_to_pdf(packtools/sps/formats/pdf/utils/file_utils.py).Ambiente utilizado
packtools, gerador de PDF (packtools/sps/formats/pdf/), LibreOffice em modo headless.