core dump in glViewer (OSX )

[dougepps]

main-line from git. compile straight-up. launch ./bin/glViewer

draws something, then core-dumps. in gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008 0x0000000107e247e3 in gldBlitFramebufferData ()

up the stack I see: OpenSubdiv/examples/glViewer/viewer.cpp:1322 (gdb) print patch.GetVertIndex () $2 = 0 (gdb) print i $3 = 0 (gdb) print patchType $4 = OpenSubdiv::v1_2_4::FarPatchTables::QUADS

Not sure if I'm un-lucky, as if this is a bug, it's gotta be hitting other people too.

[manuelk]

Hello Doug

Thanks for the head's up. Unfortunately i cannot seem to be able to produce a crash on my end. Can you give us a little bit more information ?

• OSD version
• hardware / OS / drivers

[dougepps]

apologies if my git-foo is bad.

git status

On branch master

git pull From https://github.com/PixarAnimationStudios/OpenSubdiv 12d67bf..500defe dev -> origin/dev

OSX 10.8.4 (uname -r 12.4.0)

not sure of a good way to get driver versions. Intel HD Graphics 3000:

Chipset Model: Intel HD Graphics 3000 Type: GPU Bus: Built-In VRAM (Total): 512 MB Vendor: Intel (0x8086) Device ID: 0x0126 Revision ID: 0x0009 gMux Version: 1.9.24 Displays: Color LCD: Display Type: LCD Resolution: 1920 x 1200 Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Built-In: Yes and/or AMD Radeon HD 6750M:

Chipset Model: AMD Radeon HD 6750M Type: GPU Bus: PCIe PCIe Lane Width: x8 VRAM (Total): 1024 MB Vendor: ATI (0x1002) Device ID: 0x6741 Revision ID: 0x0000 ROM Revision: 113-C0170L-573 gMux Version: 1.9.24 EFI Driver Version: 01.00.573

On Jul 12, 2013, at 9:52 AM, Manuel Kraemer notifications@github.com wrote:

Hello Doug

Thanks for the head's up. Unfortunately i cannot seem to be able to produce a crash on my end. Can you give us a little bit more information ?

OSD version hardware / OS / drivers — Reply to this email directly or view it on GitHub.

[manuelk]

Thanks - this is very helpful:

• it looks like you are using our dev branch (the OSD version is spelled in the opensubdiv/version.h file if you want to verify), which is good
• we are looking at OSX...

i'll take a look on my Mac see if i can reproduce this and hopefully track it down from there.

Thanks for bringing this to our attention.

M.

[manuelk]

I have just tried a build of the glViewer on a MacPro and it didn't crash. There are a number of factors that could be involved though, and the next step would be to take a look at the spewage from running cmake. Any chance you could paste this output here ?

[dougepps]

Attached is a file (cake.output.txt) that's the result of:

mkdir build cd build cmake ../

It also shows that for some reason it finds an old python for me (/usr/bin/python2.6) instead of what 'which python' returns.

thanks !

-doug

On Jul 15, 2013, at 7:25 PM, Manuel Kraemer notifications@github.com wrote:

I have just tried a build of the glViewer on a MacPro and it didn't crash. There are a number of factors that could be involved though, and the next step would be to take a look at the spewage from running cmake. Any chance you could paste this output here ?

— Reply to this email directly or view it on GitHub.

-- The C compiler identification is Clang 4.1.0 -- The CXX compiler identification is Clang 4.1.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Compiling OpenSubdiv version v1_2_4 -- Using cmake version 2.8.10.2 -- Try OpenMP C flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS) -- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- Found OpenCL: /System/Library/Frameworks/OpenCL.framework (Required is at least version "1.1") -- Found CUDA: /usr/local/cuda (found suitable version "4.0", minimum required is "4.0") -- Found GLFW: /usr/local/include (found suitable version "2.7.8", minimum required is "2.7.0") -- Could NOT find PTex (missing: PTEX_INCLUDE_DIR PTEX_LIBRARY) (Required is at least version "2.0") -- Found PythonInterp: /usr/bin/python2.6 (found suitable version "2.6.7", minimum required is "2.6") -- Found SWIG: /usr/local/bin/swig (found suitable version "2.0.8", minimum required is "1.3.40") -- Could NOT find Doxygen: Found unsuitable version "1.7.1", but required is at least "1.8.4" (found /usr/local/bin/doxygen) -- Found Docutils: /Library/Frameworks/Python.framework/Versions/2.7/bin/rst2html.py (found suitable version "0.9", minimum required is "0.6") -- Found Maya: /Applications/Autodesk/maya2013/Maya.app/Contents/MacOS/maya (found suitable version "201300", minimum required is "201200") CMake Warning at CMakeLists.txt:288 (message): OpenMP was not found : support for OMP parallel compute kernels will be diabled in Osd. If your compiler supports OpenMP directives, please refer to the FindOpenMP.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:310 (message): OpenGL 4.2 was not found : support for GLSL transform feedback kernels will be disabled in Osd. If you have an OpenGL SDK installed (version 4.2 or above), please refer to the FindOpenGL.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:323 (message): OpenGL 4.3 was not found : support for GLSL compute shader kernels will be disabled in Osd. If you have an OpenGL SDK installed (version 4.3 or above), please refer to the FindOpenGL.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:363 (message): Ptex was not found : the OpenSubdiv Ptex example will not be available. If you do have Ptex installed and see this message, please add your Ptex path to FindPTex.cmake in /Users/DougEpps/subd/OpenSubdiv/cmake or set it through the PTEX_LOCATION cmake command line argument or environment variable.

-- Python and SWIG found. Looking for numpy... -- Numpy package has been located. CMake Warning at documentation/CMakeLists.txt:85 (message): Doxyen was not found : support for Doxygen automated API documentation is disabled.

-- Configuring done -- Generating done -- Build files have been written to: /Users/DougEpps/subd/OpenSubdiv/build

[manuelk]

Nothing particular really jumps out here - other than CMake finds a CUDA implementation on a machine with an ATI Radeon. It's a long shot, but you could try a build with a -DNO_CUDA=1 flag to disable CUDA and see if there is any improvement. Other than that, it looks like i would need to sit in front of a reproducible case to debug this.

[dougepps]

no idea how I had cuds stuff on here. Nuking it doesn't help.

is NO_CUDA in the open subdiv stuff ? (I can't find it) or does it somehow affect OpenGL stuff ?

My case is reproducible (it immediately bombs every time), so I'll try to track down when that data is supposed to be set and see how my system is messing things up.

-doug

On Jul 30, 2013, at 5:28 PM, Manuel Kraemer notifications@github.com wrote:

Nothing particular really jumps out here - other than CMake finds a CUDA implementation on a machine with an ATI Radeon. It's a long shot, but you could try a build with a -DNO_CUDA=1 flag to disable CUDA and see if there is any improvement. Other than that, it looks like i would need to sit in front of a reproducible case to debug this.

— Reply to this email directly or view it on GitHub.

[dougepps]

Maybe I'm on to something, or maybe I'm mis-understanding what's going on. I'm consistently getting a 0 back from GetVertIndex () on a OpenSubdiv::OsdDrawContext::PatchArray.

The comment for that says "/// Returns the index of the first control vertex of the first patch /// of this array in the global PTable" which makes me think that '0' is actually the right thing, but that passing it to glDrawElements as a pointer is a "bad idea". Seems like we should be doing "something + GetVertIndex ()", where "something" is said global PTable.

But I'm not sure about that. There's lots of PTable's running around and I can't find anywhere else where GetVertex is used in this fashion, but it sure "feels strange".

Actually, API nit-pick, there are "similarly" named classes in different namespaces (e.g. PatchTable in far/patchTables.h and in osd/drawContext), which at least to my old-brain that grew up before namespaces were invented, is confusing.

[dougepps]

Seconds after writing that, I noticed what glDrawElements wants. pretending '0' is right, it seems that it's much much more complicated to figure out the array issues.

...

[dougepps]

OpenGL question:

are index 0 and 1 known to be universal for glEnableVertexAttribArray type things ? g_defaultProgram.attrPosition != 0 in my runs. ( and g_defaultProgram.attrColor != 1), in fact they're backward.

It now feels like that's a problem ?

often (in glViewer/viewer.cpp) we use g_defaultProgram.attrPosition for glEnableVertexAttribArray/glVertexAttribPointer type stuff. But a few times it's hard-coded to '0' and '1'. Where else should those maybe be fixed up ? (I'm no VBO expert )

[dougepps]

More notes from my random-walk through openGL.

It "seems" that my lack of tesselation support is at least what's giving me grief.

Do ya'll test with that code-path often ?

[dougepps]

After monkeying around with my system, it's no longer re-producible. There's still some weirdness (with holes mostly), after the 2.01 stuff, but I'm closing this until proven otherwise.

It might have been fixed a re-build of glew, which doesn't make any sense to me, but maybe that was it.