-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.AccessViolationException from SimpleRtspPlayer example #62
Comments
After some debugging with log messages it appears that this issue comes about the possibility that a decoder (e.g. FFmpegVideoDecoder) can be disposed of before, just before or during the use of its handle in the FFmpeg library methods. This disposal appears to remove the memory allocation for the frame as well as possibly other objects, causing the exceptions based on the timing of these events. Perhaps using a locked object (or atleast checking disposal state) when using the decoder could prevent use when it is being disposed or disposal during use. Though for many of the logs i could catch the _disposed field wasn't set just before a action (e.g. scaling/decoding using the library). For reference in the following console logs: Some logs for reference: attempting use of already disposed decoder (which could have been prevented)
attempting use of the decoder which has started being disposed
stacktrace from attempting to scale frame
non-crashing case I came across?
|
@MysticMight Hi, did you find a fix about this issue ? I'm trying to fix the _disposed field issue you are talking about but still have the crash. Thanks ! |
Yes, I believe so. I just haven't gotten the chance to submit a pull request yet. I may submit it this week. |
@MysticMight I added your fix to my own project - so far everything works fine. Speaking of this file - do you think it may have sense to protect _scalersMap as well? In my code I am also locking _scalersMap, because TransformTo may attempt to add scaler while DropAllVideoScalers will be doing "foreach". |
@RandDruid Yes I guess so. I haven't noticed any issues for it, but it'll atleast prevent it doing extra work when unnecessary (creating a scaler) and of course properly closing the scalar, depending on the timing. Did you just add the same disposal lock over |
@MysticMight I did it in a pretty simple way |
Describe the bug
A unhandled AccessViolation exception which occurs when disconnecting (see reproduction steps). I've noticed this same issue in my own project, which uses the decoding implementation from SimpleRtspPlayer, and have been able to reproduce it in a fork of RtspClientSharp. However it is much more observable in my (closed-source) project then the RtspClientSharp fork, and often causes a crash on a single disconnect from the server. To observe more details I enabled native code debugging and found a error in avcodec-58.dll, so I am not sure if this is specific to this project or FFMPEG.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect there to likely be issues when disconnecting/reconnecting too quickly (e.g. if a object is disposed or still exists), however from my experience it also occurs sometimes on a single disconnect (though I've only seen this in my program so far). Ideally the cause of the exception would be fixed, or at least not cause a crash.
Screenshots
First Exception (only when native debugging is on for SimpleRtspPlayer):
Exception thrown at 0x79B45CA0 (avcodec-58.dll) in CrawlerRTSPClient.exe: 0xC0000005: Access violation reading location 0x00001602.
Exception:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
stacktrace below:
Stacktrace
Desktop (please complete the following information):
Additional context
Not sure if this is too relevant, here are some details on some adjustments I made to the project for my environment:
In order to build with my environment I found I needed to adjust the libffmeghelper's WindowsTargetPlatformVersion to 10.0.15063.0 (to use the default SDK). I also changed the SimpleRtspClient's supported runTime and target framework version to v4.6.1.
I am intending to use a UDP connection.
The text was updated successfully, but these errors were encountered: