<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
xxcv wrote:
<blockquote cite="mid:4AA6D3DC.5070502@gmail.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Geoffroy Couprie wrote:
<blockquote cite="mid:4AA65BEE.6050107@videolan.org" type="cite">
<pre wrap="">Hello,
xxcv a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I've encountered a strange problem...
This bug, triggered, when quitting vlc -Iqt <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://stream">http://stream</a>
When stop is pressed (embedded) it'll bring up the vlc.exe has stopped
working dialog, pressing close will leave the gui in a locked up state
(will end up looking like this, in attached file).
when stop is pressed (non-embedded) same vlc.exe stopped working
dialog is shown, pressing close will not lock up the gui.
Here's the interesting part. In non-embedded after pressing close,
then, press play again (it works), press stop it won't crash anymore,
even after few retries.
So, in non-embedded mode it will only crash exactly once initially
pressed stop.
</pre>
</blockquote>
<pre wrap=""><!---->Could you explain a bit? Are you talking about embedded video?
</pre>
</blockquote>
yes<br>
<blockquote cite="mid:4AA65BEE.6050107@videolan.org" type="cite">
<blockquote type="cite">
<pre wrap="">After some tracing in the access delete code I found out that it
triggered the crash at exactly this line:
vlc_object_release( p_access );
</pre>
</blockquote>
<pre wrap=""><!---->File? Line?
</pre>
</blockquote>
input access.c 2nd last line.<br>
<blockquote cite="mid:4AA65BEE.6050107@videolan.org" type="cite">
<blockquote type="cite">
<pre wrap="">Problem signature:
Problem Event Name: APPCRASH
Application Name: vlc.exe
Application Version: 1.1.0.99
Application Timestamp: 4aa62492
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6002.18005
Fault Module Timestamp: 49e041d1
Exception Code: 40010006
Exception Offset: 000000000000dbe8
I assume this is some sort of assert somewhere ... As this bug is
un-reproducible inside gdb 64-bits
Doesn't trigger when quitting vlc -Idummy <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://stream">http://stream</a>
</pre>
</blockquote>
<pre wrap=""><!---->AFAIK, this exception code has nothing to do with VLC (that's an
exception received if some kernel code sent a debug string). Could you
get a backtrace?
</pre>
</blockquote>
ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7<br>
ntoskrnl.exe!memset+0x22a<br>
ntoskrnl.exe!KeWaitForSingleObject+0x2cb<br>
ntoskrnl.exe!KeDetachProcess+0x120d<br>
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3<br>
ntoskrnl.exe!memset+0x4df<br>
ntoskrnl.exe!KeWaitForMultipleObjects+0x2eb<br>
ntoskrnl.exe!NtQueryInformationThread+0x102e<br>
ntoskrnl.exe!NtQueryInformationThread+0x1673<br>
ntoskrnl.exe!ZwUnloadKeyEx+0x20d3<br>
ntdll.dll!NtWaitForMultipleObjects+0xa<br>
kernel32.dll!FlsSetValue+0x7b3<br>
kernel32.dll!LoadModule+0x6fe<br>
kernel32.dll!LoadModule+0x887<br>
kernel32.dll!UnhandledExceptionFilter+0x1ff<br>
ntdll.dll!RtlIpv4AddressToStringA+0x1cb<br>
ntdll.dll!_C_specific_handler+0x27d<br>
ntdll.dll!RtlRaiseException+0xe1<br>
kernel32.dll!OutputDebugStringA+0xb8<br>
msvcrt.dll!assert+0x7d0<br>
msvcrt.dll!invalid_parameter+0x13<br>
msvcrt.dll!pow+0x22d4<br>
libvlccore.dll!vlc_object_get_name+0x18f<br>
This is the thread I think have caused it.<br>
</blockquote>
Hi,<br>
If like you said it has nothing to do with vlc, I am thinking why, its
triggered exactly only once in the non-embedded video qvlc instance?<br>
Help me find the problem.<br>
</body>
</html>