1>log1.txt

in the post from 2014-01-19 01:32:38
i uploaded a wrong log file... here is a one with a crash

BTW.: under linux ubuntu 13.10 and 'blender-2.69-7436a3f-linux-glibc211-x86_64.tar.bz2' (on the same hardware environment), the clip was tracked without crash.

Is there anything usable in C:\Users\John\AppData\Local\Temp\blender.crash.txt after the crash?

Couldn't actually reproduce the issue. Does it depend on file format, resolution and number of tracks being tracked?

@Thomas Dinges (dingto), mind checking this on your computer?

@Sergey Sharybin (sergey): unfortunately no, in the blender.crash.txt is nothing usefully that would point to the cause of the crash.
i have a second computer with exact the same hardware, but different GPU - on that computer blender crash as well.
and my third, my business laptop (i Core2 Duo T7500, 4GB, Windows 7 64bit SP1, )
what i exactly was doing:

1. downloaded blender (blender-2.69-fd0b104-win64.zip-version)
2. extracted to here ("D:\_DOWNLOADS\_unsorted\blender-2.69-fd0b104-win64")
3. deleted "%AppData%\Blender Foundation" folder to be sure noting old will interfering
4. downloded "0001-2654.mp4" (to "D:\_TEMP\0001-2654.mp4")
5. opened blender
6. changed screen to "Motion Tracking"
7. on the lower "Movie Clip Editor" i clicked to "Open" (bpy.ops.clip.open())
8. navigate to "0001-2654.mp4" file destination and selected that file
9. clicked "Open Clip" (bpy.ops.file.execute())
10. changed in lowest time line view the end frame to 2654 (bpy.data.scene["Scene"].frame_end)
11. in the "Movie Clip Editor" view, i scrolled "two" times the mouse wheel to decrease the view size of the video clip to fit to the view
12. on the "Movie Clip Editor"s left Marker panel i clicked "Detect Features" (bpy.ops.clip.detect_features())
13. in the "Movie Clip Editor"s left Track panel, i clicked ">" (bpy.ops.clip.track_markers(backwards=False, sequence=True))
14. i leave the system & mouse & keyboard untouched... and watch the progress in the viewport

(the crash happens on different frames from computer to computer and sometimes from try to try)

on my business laptop is tried to attach the debugger of VisualStudio 2010 to a running blender process and processed all the above steps...
but blender closes and the debugger could not catch any exception - maybe i did something wrong - Native code (debugging) is not my favorit part.

except of some Access violation writing location during UI i got nothing
"First-chance exception at 0x00000000140913aa in blender.exe_ 0cC0000005: Access violation writing location 0x0000000003cdcf68."
"First-chance exception at 0x068415e9 (nvoglv64.dll) in blender.exe_ 0cC0000005: Access violation writing location 0x0000000003cdceb4."

I can confirm the same crash on my computer. It happens exactly as described in first post. I did some tests on different versions of blender, both 32-bit and 64-bit.

Blender version 2.66a and older seems to work.
Blender version 2.67 and later crashes.

My system:
Windows 7 64-bit, 16GB RAM, i7-4770 CPU using Intel HD Graphics 4600

I also tried other lower resolution png-sequences only about 350 frames long. They could crash too but I had to use many more markers before it happened. Prefetching the frames seemed to help at first but after some tries it also crashed.
Changing Memory Cache Limit in preferences didn't seem to make any difference.

One thing I noticed when tracking the attached test-file, was that Blender version 2.67 and later would track fast in the beginning then slower and slower (like 4 frames a second) then not update the screen for a few seconds and then suddenly jump forward hundreds of frames having tracked all frames correctly but very much faster during the freeze. Don't know if it's related to this bug.

Hope this helps to narrow it down.

Does anyone noticed memory usages of blender? Does it run out of memory or so?

@Sergey Sharybin (sergey): no, not on my three computers.
i can not observe any abnormal or extensive memory usage on my computer.
on the tiniest laptop with 4GB RAM, blender uses ~1GB during tracking.
the memory usage follows a normal loading curve with saturation at ~1GB usage long before blender will crash.

I've committed a fix (rB910f4df) which potentially fixes this bug. Please grab a build which includes this fix and give it a try.

I tried the latest build from buildbot (blender-2.69-b096845, both 32 and 64 bit) and did some quick tests. Everything is working fine here. It doesn't crash anymore and the occasional freezing of the screen issue I mentioned earlier seems to have been fixed as well. Thanks.

yes, i can confirm, blender-2.69-b096845-win64.zip works well... thanks!