crashes when importing a pdf (Windows)

[Benjamin Phillips]

Crashes after attempting to import a pdf. Attached is the file. On Inkscape 0.48.2 on Windows 7 64 bit.

[Benjamin Phillips (benphill)]

here are the specific error messages it gives before crashing.

[su_v (suv-lp)]

On OS X 10.7.4 (with poppler 0.18.4 and 0.20.3), Inkscape 0.48.3.1 and 0.48+devel r11856 simply hangs even before opening the PDf import dialog with the page preview, same on Ubuntu 12.10 (with poppler 2.20.4). Same happens when trying to open the PDF file with the 'Adobe PDF via poppler-cairo (*.pdf)' experimental file format in current trunk.

Since Evince 2.30.2 and 3.6.0 (poppler-based PDF viewer) also hang when trying to render the PDF file (on OS X as well as Ubuntu), this looks more like an issue in upstream poppler and not Inkscape itself.

Ghostscript 0.9.6, Xpdf 3.02 and Apple's Preview.app OTOH open the file just fine (Preview is unusually slow to load and pan the document though)

Attaching a random sample of hanging Inkscape process (after about 30-50 sec) on OS X (with poppler 2.20.3).

[jazzynico (jazzynico)]

Also hangs, but doesn't crash on Windows XP, Inkscape trunk revision 11859. Then editing the map is very slow.
Opens and render as expected with Acrobat reader 9.

[jazzynico (jazzynico)]

Crash confirmed on Windows XP, Inkscape 0.48.3.1.
After a 10 minutes hang, the application stops with Glib-ERROR**:gmem.c errors (as shown in the file comment #2).

Similar to "Bug #846389 uploading (big) PDF file load *physical* memory until crash", except that in the current report the file is not big enough to crash the trunk versions.

[su_v (suv-lp)]

> Also hangs, but doesn't crash on Windows XP, Inkscape
> trunk revision 11859. Then editing the map is very slow.

I wasn't patient enough to time the actual loading of the file: on OS X 10.7.4 (2.4 GHz Intel Core i5, 8GB RAM), with poppler 0.18.4 and cairo 1.12.2 installed, current trunk takes about 3 - 3.5 minutes until the 'PDF import settings' dialog with the preview image opens, and then another 1.5 minutes until the drawing opens in the main window.

This is unusual based on my experience: normally, the 'PDF import settings' dialog with the preview (created with poppler-cairo) opens rather quickly, and Inkscape's own PDF import routines then take much longer (up to several minutes) until the selected page of the PDF file is finally opened in the main window.

[babayasin (serge-timakov)]

Inkscape 0.48.3.1 r9886 hangs without any dialog or console message on any PDF file import on Debian testing amd_64 w/ libpoppler19 and libpoppler44 .

Evince shows PDF files as usual.

PDF export from Inkscape: OK.

Same version of Inkscape on same Debian testing but 32-bit had no problems with PDF import.

[Nathan Lee (nathan.lee)]

Not replicated in Inkscape 1.0.1 (3bc2e813f5, 2020-09-07) x32 bit and x64 bit Windows 10 or Arch (1.0.1-2). There is a long hang on preview and on load, but no crash

I do crash in 0.48.2 32 bit Windows 10 though (popup comes up but its all black and disappears before it renders properly). running from inkscape.com, I do see the following message though:

RegistryTOol: Could not create the registry key 'SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\inkscape.exe'
terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc

Emergency save activiated!
... (sorry, I'm typing out the error message, skipping this common bit)

***MEMORY-ERROR***: inkscape.exe[4036]: GSlice: failed to allocate 4088 bytes (alignment: 4096): Not enough space

------------

Since I no longer replicate in 1.0 on Windows 10, closing as fixed, as part of the bug migration to Gitlab (see https://alpha.inkscape.org/bug-migration/). If this problem does still occur for you in 0.92.5 or later, please create a new issue in our new bugtracker at inkscape.org/report (should redirect to it).

Thanks for reporting this bug!

[Nathan Lee (nathan.lee)]

For completeness, here's a backtrace from 0.48.2. Also, not replicated in 0.92.5 Windows 10.

a rough summary: bunch of unknown symbols `#5370 0x005d3050 in ?? ()` before an error is raised

#5338 0x76cd83c1 in raise () from C:\Windows\System32\msvcrt.dll
#5339 0x00000016 in ?? ()
#5340 0x76cdc84b in msvcrt!abort () from C:\Windows\System32\msvcrt.dll

Then the roughly 5000+ other frames are trying to print the error message, and I assume not having enough memory to do so.