r7922 - Segfault loading webm or mkv on OSX in mkvHeader::addIndexEntry

[nibbles]

I get a Segfault 11 when I try to open any webm or mkv with 2.6 when it is compiled with clang on OSX.  It does not happen with llvm-gcc.  So I never reported it, but this has been happening since December.  Because clang is more strict with C++ standards, this might be worth investigating.  For my sample video, I'm using a webm I downloaded from Youtube of grapefruit sized hail.

Error Summary:

Code Select Expand

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x000000010a7b8799 in mkvHeader::addIndexEntry (this=0x106872200, track=1, parser=0x7fff5fbfd1c8, where=4331, size=4,
    flags=0, timecodeMS=0) at /tmp/homebrew-avidemux3-2.6-LBre/avidemux_plugins/ADM_demuxers/Matroska/ADM_mkvIndexer.cpp:208
208   Track->index.append(ix);


Steps to Reproduce:
  Build avidemux in debug or release mode using clang-3.1.
  Open this file (15MB):  https://rapidshare.com/files/2220430436/OKC_Hail_5-10-2010.webm
  Segfault 11 before it finishes loading during the Matroska Images phase.
  This occurs with avidemux and avidemux_cli, with or without OpenGL enabled.

Logfiles:  I have pasted into several gists the following data:

• The MediaInfo for the video
• The Avidemux compile log building with clang in case there's a useful warning about incompatible pointers
• The Avidemux run log copied from the terminal when loading the video
• The OSX Crash Report
• The gdb bt full with clang
• The gdb bt full with llvm-gcc for comparison to see what it looks like when it works
• The gdb disass $pc-32,$pc+32
• The gdb info all-registers

Okay, thanks for your help.

[mean]

The sample did not get to github

[Jan Gruuthuse]

the reply from raw.github.com is:

Error: blob is too big

Guess you better use ... for now, free account leaves file for approx. 1 month on there.

[nibbles]

I fixed the video url in my original post to use Rapidshare and tested it.  The sha1 of that video is f8cf0c267bbbe59a053b50827a3974dc08a9af95

[mean]

works here with gcc, let's see with clang

[mean]

crash with clang
Seems to be related to templates

[nibbles]

Thanks for checking.  This may have some template info: http://clang.llvm.org/compatibility.html
Let me know if I can gather any more data.

[mean]

Probably fixed

[nibbles]

YES!  Thanks for your time.  It is always appreciated.  I'm so glad I can now allow clang in my 2.6 formula.  Even that smurfing swap U & V issue is gone in the last 10 commits or so.  Great job!