Page MenuHome

OBJ Importer Crash
Confirmed, NormalPublic

Description

System Information
Operating system: Windows 10
Graphics card: Nvidia Quadro P5000

Blender Version
Broken: 2.91.2
Worked: N/A

OBJ Importer crashes while attempting to import OBJ file.

Steps to reproduce:

  1. Download attached OBJ
  2. File > Import > Wavefront (obj)
  3. Select OBJ, click "Import OBJ"

Actual Behavior:
Blender crashes.

Expected Behavior:
The OBJ file is imported successfully.


Event Timeline

Imports fine here. Linux 2.92.0 RC and 2.91.2
I suspect a local problem.
Any interesting error messages?

Seems like it's something with my system... You know what... I should've provided you with more debugging info, my bad.

Here's what I get when I run it from the console:

PS C:\Programs\blender> .\blender.exe
Read prefs: C:\Users\me\AppData\Roaming\Blender Foundation\Blender\2.91\config\userpref.blend
found bundled python: C:\Programs\blender\2.91\python
Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF8E52427DA
Module  : Wintab32.dll
Thread  : 000056c4
Writing: C:\Users\me\AppData\Local\Temp\blender.crash.txt

I think this may be an isolated issue on my system if it imports fine for you. I haven't updated Windows in a while to keep it running stable, so this may be the cause.

In any case, I have attached the crash report.

Thanks!

Update: I have installed the latest GPU drivers, but it seems this is related to the tablet drivers (based on searches for wintab32.dll)... I do use a tablet screen, so I think this may have something to do with Wacom's drivers or something...

Ernesto Méndez (mendezcode) claimed this task.

Sooo.... I was able to fix it! This actually is not a localized problem but it does seem like a bug.

I was able to import fine after setting the Tablet API to "Windows Ink" on Preferences > Input.

That being said, this doesn't seem to be a bug with the OBJ importer per se, but this highlights another possible bug which involves Blender crashing when using "WinTab" as tablet API for some reason.

In any case, I'm glad it's solved, thanks again!

Nicholas Rishel (nicholas_rishel) reopened this task as Confirmed.EditedSun, Feb 21, 7:37 AM

What's happening here is that while the window is being destroyed, it closes the Wintab context via WTClose. The Wintab library must be calling one of the Win32 functions which allows callbacks to the Windows event loop to run, which calls an event which uses Wintab after it's closed and while Ghost's window is half torn down.

The solution here is to not trust Wintab when tearing down the window to not reenter, and close before the GHOST_WindowWin32's destructor. Reopening as this is a legitimate issue.

Edit: The issue is reentrancy while GHOST_WindowWin32 is being torn down, but it's not Wintab that triggers it, Wintab being passed a closed context is just the last step. Looks like it's the call to DestroyWindow from the stack trace.

Edit2: Without logging with the specific device, it could be quite difficult to narrow down the exact cause. E.g. it could be that the Wintab library is not handling multiple contexts for a single process correctly and thus closing the wrong one, or reentrancy is causing a half-destroyed window with closed Wintab context to crash.