[vlc-devel] Win64 access http with gui

[xxcv]

xxcv wrote:
> Geoffroy Couprie wrote:
>> Hello,
>>
>> xxcv a écrit :
>>   
>>> Hi,
>>> I've encountered a strange problem...
>>> This bug, triggered, when quitting vlc -Iqt http://stream
>>> 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.
>>>     
>> Could you explain a bit? Are you talking about embedded video?
>>   
> yes
>>> 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 );
>>>     
>> File? Line?
>>   
> input access.c 2nd last line.
>>> 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 http://stream
>>>     
>> 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?
>>   
> ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7
> ntoskrnl.exe!memset+0x22a
> ntoskrnl.exe!KeWaitForSingleObject+0x2cb
> ntoskrnl.exe!KeDetachProcess+0x120d
> ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3
> ntoskrnl.exe!memset+0x4df
> ntoskrnl.exe!KeWaitForMultipleObjects+0x2eb
> ntoskrnl.exe!NtQueryInformationThread+0x102e
> ntoskrnl.exe!NtQueryInformationThread+0x1673
> ntoskrnl.exe!ZwUnloadKeyEx+0x20d3
> ntdll.dll!NtWaitForMultipleObjects+0xa
> kernel32.dll!FlsSetValue+0x7b3
> kernel32.dll!LoadModule+0x6fe
> kernel32.dll!LoadModule+0x887
> kernel32.dll!UnhandledExceptionFilter+0x1ff
> ntdll.dll!RtlIpv4AddressToStringA+0x1cb
> ntdll.dll!_C_specific_handler+0x27d
> ntdll.dll!RtlRaiseException+0xe1
> kernel32.dll!OutputDebugStringA+0xb8
> msvcrt.dll!assert+0x7d0
> msvcrt.dll!invalid_parameter+0x13
> msvcrt.dll!pow+0x22d4
> libvlccore.dll!vlc_object_get_name+0x18f
> This is the thread I think have caused it.
Hi,
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?
Help me find the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090910/7272655e/attachment.html>