|
|
| dloneranger |
| Posted: Jan 24 2011, 01:51 AM |
 |
|
Moderator
  
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07

|
Finally got it to crash !!
I'm just looking through the source code now and seeing what should be submitted as possible problem
It seems to be triggered after an 'out of memory' error Virtualdub can attempt to access a non-existent frame buffer
Unfortunately I'm only a beginner at c++, so while I can find the crash, I'll let Phaeron fix it properly
-------------------- MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask Windows7/8 Codec Chooser All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
 |
| evropej |
| Posted: Jan 24 2011, 02:39 PM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
I forgot to mention but how did you get vdub to open mov files automatically without entering the type and extended options? Also, how do you set the filter set to appear automatically?
Out of this whole discussion, one great useful fact "Force single framebuffer" made some of my filter work finally and come crashes stopped. Thanks for all the input thus far. |
 |
| dloneranger |
| Posted: Jan 24 2011, 03:51 PM |
 |
|
Moderator
  
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07

|
| QUOTE | I forgot to mention but how did you get vdub to open mov files automatically without entering the type and extended options? Also, how do you set the filter set to appear automatically? |
It's my modified version of virtualdub - it does some useful things and some bizarre ones The only reason I wanted you to try that was to narrow down the point of failure that causes the crash - I wasn't sure if any changes I had made were causing it to crash less than the normal one
I posted a bug report on it, hopefully Phaeron can track it down from that
-------------------- MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask Windows7/8 Codec Chooser All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
 |
| evropej |
| Posted: Jan 25 2011, 05:10 AM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
Thanks I hope he fixes the bug because loading all those filters takes time lol
check this out lol http://www.evropej.com/lol/lol.html |
 |
| phaeron |
| Posted: Jan 30 2011, 01:45 AM |
 |
|

Virtualdub Developer
  
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02

|
Basically, the way it works is that if you have a filter that needs the "force single framebuffer" option to work, then bad things can happen if it isn't -- specifically, the filter can corrupt memory when it runs. I need to put in an option to make this sticky by default for some filters. |
 |
| evropej |
| Posted: Jan 31 2011, 03:22 AM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
What if the option is already selected and there is a crash?
Side note, why do I get better performance with lower number of video buffers? I have 12 gigs of ram lol. |
 |
| ale5000 |
| Posted: Jan 31 2011, 06:27 AM |
 |
|

Advanced Member
  
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07

|
If you are using the 32-bit version your 12GB are useless, the only way to use them is to use the 64-bit version.
-------------------- New VirtualDub forum VirtualDub AIO (All-in-One installer for VirtualDub and plugins) Codec Toolbox RS (A tool to read/change merit of codecs and many other things) Input plugins for VirtualDub / ACM codecs / VFW codecs |
 |
| evropej |
| Posted: Feb 1 2011, 05:45 PM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
Yes thank you, I do realize that. If you notice, I wrote that if windows xp supported more than 3 gigs of ram, I would not use a Windows 7 64 bit. Point was, I have a lot of ram available. |
 |
| ale5000 |
| Posted: Feb 1 2011, 08:38 PM |
 |
|

Advanced Member
  
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07

|
My point was mainly that if you use a 32-bit VirtualDub on a 64-bit Windows then your 12GB still can't be used 
However there is also Windows XP x64
-------------------- New VirtualDub forum VirtualDub AIO (All-in-One installer for VirtualDub and plugins) Codec Toolbox RS (A tool to read/change merit of codecs and many other things) Input plugins for VirtualDub / ACM codecs / VFW codecs |
 |
| evropej |
| Posted: Feb 2 2011, 02:13 AM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
I have tried windows xp 64 and was not impressed with the support. In either case, I hope the big chief decides to fix the issue. |
 |
| phaeron |
| Posted: Feb 5 2011, 07:13 PM |
 |
|

Virtualdub Developer
  
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02

|
| QUOTE (evropej @ Jan 30 2011, 08:22 PM) | | Side note, why do I get better performance with lower number of video buffers? I have 12 gigs of ram lol. | How many video buffers do you have? If you're running out of memory, this may be part of it. |
 |
| evropej |
| Posted: Feb 6 2011, 12:15 AM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
I cranked the video memory up and buffers all the way to right when I work on pixelation/resolution issues. I usually have to crank these all the way to the left when I use deshaker. Deshaker works much better on playback with minimal buffers. The crashes still happen though no matter what buffer option I choose. |
 |
| phaeron |
| Posted: Feb 13 2011, 11:35 PM |
 |
|

Virtualdub Developer
  
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02

|
Found the problem. It appears to be a bug in the code that merges filter allocators, causing the smaller frames to use larger buffers than necessary. Unfortunately my dev branch is not in a good state to push a test release, but there are two fixes required.
FilterInstance.cpp:
| CODE | void FilterInstance::RegisterAllocatorProxies(VDFilterFrameAllocatorManager *mgr, VDFilterFrameAllocatorProxy *prev) { mSourceAllocator.Clear();
if (!(mFlags & FILTERPARAM_SWAP_BUFFERS)) mResultAllocator.Link(prev);
mgr->AddAllocatorProxy(&mSourceAllocator);
if (!mbAccelerated) mSourceAllocator.AddSizeRequirement(mRealSrc.size + mRealSrc.offset);
prev->AddBorderRequirement(mRealSrc.mBorderWidth, mRealSrc.mBorderHeight); |
FilterFrameAllocatorManager.cpp:
| CODE | } else { VDASSERT(ent1.mMaxSize <= ent2.mMinSize);
float mergeRatio = 0.f;
if (ent2.mMaxSize) mergeRatio = (float)ent1.mMinSize / (float)ent2.mMaxSize;
if (mergeRatio > bestMergeRatio) { bestMerge = i; bestMergeRatio = mergeRatio; } }
|
In the filter chain I tested, this reduces memory usage by about half, so it won't solve all memory problems, but it should give more breathing room. A significant amount of memory is also being taken up by internal buffers in the filters themselves, which these fixes won't change. Beyond that I think the only quick fix might be to mark the executable /LARGEADDRESSAWARE, which on x64 systems will raise the 32-bit process commit limit from about 1.6GB to about 3.8GB. I haven't tried doing that yet, so I have no idea what might break (there can be compatibility problems with some DLLs, such as D3DX).
If you're still hitting the problem, please open Task Manager while the crash dialog is still up, enable the VM Size (Windows XP) or Process Commit Size (Windows Vista/7) column, and check how much memory VirtualDub is using. |
 |
| evropej |
| Posted: Feb 20 2011, 12:20 AM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
Thanks for the update, I will give it a try later. Right now I have to wait for a day for all the videos to deshake from my ski trip. I am putting this core i7 to work lol. |
 |
| evropej |
| Posted: Feb 20 2011, 07:48 PM |
 |
|
Advanced Member
  
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09

|
I had to work hard to get it to crash but I did. I am working on my machine with a monitor which supports a much smaller resoultion same machine though.
Anyway, the size used was 650 megs but the commit size was 1.35 gigs. I am using 1.1 
VirtualDub crash report -- build 33848 (release) --------------------------------------
Disassembly: 091a2c80: b614 mov dh, 14h 091a2c82: 380f cmp [edi], cl 091a2c84: b60c mov dh, 0ch 091a2c86: 18895424300f sbb [ecx+f302454], cl 091a2c8c: b614 mov dh, 14h 091a2c8e: 28894c24348b sub [ecx-74cbdbb4], cl 091a2c94: 4c dec esp 091a2c95: 2454 and al, 54h 091a2c97: 2911 sub [ecx], edx 091a2c99: 83410cff add dword ptr [ecx+0ch], 0ffh 091a2c9d: 8b542434 mov edx, [esp+34h] 091a2ca1: 295104 sub [ecx+04h], edx 091a2ca4: 8b542430 mov edx, [esp+30h] 091a2ca8: 295108 sub [ecx+08h], edx 091a2cab: 0fb61418 movzx edx, byte ptr [eax+ebx] 091a2caf: 0fb60c38 movzx ecx, byte ptr [eax+edi] 091a2cb3: 89542454 mov [esp+54h], edx 091a2cb7: 0fb61428 movzx edx, byte ptr [eax+ebp] 091a2cbb: 0116 add [esi], edx 091a2cbd: 8b542454 mov edx, [esp+54h] 091a2cc1: 015604 add [esi+04h], edx 091a2cc4: 99 cdq 091a2cc5: f77c244c idiv eax, dword ptr [esp+4ch] 091a2cc9: 014e08 add [esi+08h], ecx 091a2ccc: 83460c01 add dword ptr [esi+0ch], 01h 091a2cd0: 85d2 test edx, edx 091a2cd2: 0f85bbf9ffff jnz 091a2693 091a2cd8: 5e pop esi 091a2cd9: 5f pop edi 091a2cda: 5d pop ebp 091a2cdb: 5b pop ebx 091a2cdc: 83c428 add esp, 28h 091a2cdf: c3 ret 091a2ce0: 81ec88000000 sub esp, 00000088 091a2ce6: 53 push ebx 091a2ce7: 55 push ebp 091a2ce8: 56 push esi 091a2ce9: 8bb424a8000000 mov esi, [esp+a8] 091a2cf0: 8bee mov ebp, esi 091a2cf2: 0fafac24ac0000 imul ebp, [esp+ac] 00 091a2cfa: 57 push edi 091a2cfb: 8bfd mov edi, ebp 091a2cfd: c1e704 shl edi, 04h 091a2d00: 57 push edi 091a2d01: e895810000 call 091aae9b 091a2d06: 8bd8 mov ebx, eax 091a2d08: 8bcf mov ecx, edi 091a2d0a: 8bd1 mov edx, ecx 091a2d0c: c1e902 shr ecx, 02h 091a2d0f: 33c0 xor eax, eax 091a2d11: 8bfb mov edi, ebx 091a2d13: f3ab rep stosd <-- FAULT 091a2d15: 8bca mov ecx, edx 091a2d17: 8b9424a0000000 mov edx, [esp+a0] 091a2d1e: 83e103 and ecx, 03h 091a2d21: f3aa rep stosb 091a2d23: 8bcd mov ecx, ebp 091a2d25: 33c0 xor eax, eax 091a2d27: 8bfa mov edi, edx 091a2d29: f3ab rep stosd 091a2d2b: 8b8424a4000000 mov eax, [esp+a4] 091a2d32: b901000000 mov ecx, 00000001 091a2d37: 890a mov [edx], ecx 091a2d39: 0fb638 movzx edi, byte ptr [eax] 091a2d3c: 017b10 add [ebx+10h], edi 091a2d3f: 8bbc24a8000000 mov edi, [esp+a8] 091a2d46: 0fb62f movzx ebp, byte ptr [edi] 091a2d49: 016b14 add [ebx+14h], ebp 091a2d4c: 8bac24ac000000 mov ebp, [esp+ac] 091a2d53: 0fb66d00 movzx ebp, byte ptr [ebp+00h] 091a2d57: 016b18 add [ebx+18h], ebp 091a2d5a: 014b1c add [ebx+1ch], ecx 091a2d5d: 8bac24bc000000 mov ebp, [esp+bc] 091a2d64: 83c404 add esp, 04h 091a2d67: 3bf1 cmp esi, ecx 091a2d69: 895c241c mov [esp+1ch], ebx 091a2d6d: 8b9c24bc000000 mov ebx, [esp+bc] 091a2d74: 894c2478 mov [esp+78h], ecx 091a2d78: 894c2428 mov [esp+28h], ecx 091a2d7c: 0f db 0fh 091a2d7d: 8e7601 mov ?6s, [esi+01h]
Built on Aegis on Fri Dec 24 13:11:24 2010 using compiler version 1400
Windows 6.1 (Windows Vista x64 build 7600) []
EAX = 00000000 EBX = 00000000 ECX = 0146d000 EDX = 051b4000 EBP = 0051b400 ESI = 00000a60 EDI = 00000000 ESP = 0018fbe0 EIP = 091a2d13 EFLAGS = 00210246 FPUCW = 027f FPUTW = ffff
Crash reason: Access Violation
Crash context: An out-of-bounds memory access (access violation) occurred in module 'MSU_Cartoonizer'...
...writing address 00000000...
...while running filter "MSU Cartoonizer v 3.0" (FilterInstance.cpp:1954).
Pointer dumps:
EDX 051b4000: 00000000 00000000 00000000 6c720000 72206d68 706c6265 00006170 00001000 ESP 0018fbe0: 051b4000 071c3c84 071c3c58 00000000 071c3c78 48949520 000007dd 00000001 0018fc00: 4894a9e0 4b769f81 00000a5d 00000a5f 000014c0 00002980 000000ff 00000000 0018fc20: 00000a5f 4b769f80 000007de 4db45380 4b76a9e0 4b76a9e0 00000a50 000007de 0018fc40: 00000a5d 4d105380 00000a5f 00000a60 000007e0 00000a60 000007e0 000014c0 EBP 0051b400: 244c8d00 d0b6e814 4c8dfff2 44c70c24 6a241024 4c890062 8d561c24 c714244c 0051b420: 002c2444 e8000000 fff2da24 4c8dc085 950f1024 2444c7c3 ffffff28 d09ee8ff 0051b440: db84fff2 8b1c745b 89082454 b05f0857 4c8b5e01 89641424 0000000d 20c48300 0051b460: 8b0004c2 5f1c244c 645ec032 00000d89 c4830000 0004c220 cccccccc cccccccc
Thread call stack: 091a2d13: MSU_Cartoonizer!VirtualdubFilterModuleDeinit [09110000+3380+8f993] 0911471c: MSU_Cartoonizer!VirtualdubFilterModuleDeinit [09110000+3380+139c] 0911da94: MSU_Cartoonizer!VirtualdubFilterModuleDeinit [09110000+3380+a714] 091134df: MSU_Cartoonizer!VirtualdubFilterModuleDeinit [09110000+3380+15f] 0043d153: FilterInstance::RunFilterInner() 00438e10: VDFilterFrameManualSource::GetNextRequest() 0043eec6: _catch$?RunFilter@FilterInstance@@IAEXXZ$0() 0043f60a: FilterInstance::RunProcess() 00444431: FilterSystem::Run() 0046aa96: VDProject::UpdateFrame() 76666941: USER32!gapfnScSendMessage [76650000+15fc8+979] 76666901: USER32!gapfnScSendMessage [76650000+15fc8+939] 76667d31: USER32!LoadStringW [76650000+17c12+11f] 7667028d: USER32!PeekMessageW [76650000+20112+17b] 76670243: USER32!PeekMessageW [76650000+20112+131] 7668eec0: USER32!PeekMessageA [76650000+3ed58+168] 0046d613: VDProject::Tick() 0045a4fc: WinMain@16() 005d66cb: __tmainCRTStartup() 76763677: kernel32!BaseThreadInitThunk [76750000+13665+12] 77179f02: ntdll!RtlInitializeExceptionChain [77140000+39e9f+63] 77179ed5: ntdll!RtlInitializeExceptionChain [77140000+39e9f+36]
-- End of report |
 |