Closed omegaman1 closed 10 years ago
hi thanks for the note. I've tried reproducing this on windows 7 and so far I'm not crashing with DEP turned on when i run attract 1.2.2. I haven't had a chance to try on xp yet.
Which version of windows are you using? Is there anything in particular you are doing to get it to crash? also if you've got videos set up to play what format are they in? Its possible the video decoder could be causing this...
I see from the log on the other thread that you are on 64 bit windows. I wonder if that is the cause.
Unfortunately I don't have 64 bit windows to test on...
I assume if no other users have complained about the same issue with attract running on 32 bit win then that probably is a safe bet. I have a spare machine loaded with vista 32 lying around somewhere, I'll try running attract on that with DEP on and see what happens just for the sake of doing so. Thanks... Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Wednesday, May 14, 2014 11:55 PM, Andrew Mickelson notifications@github.com wrote:
I see from the log on the other thread that your on 64 bit windows. I wonder if that is the cause. Unfortunately I don't have 64 bit windows to test on... — Reply to this email directly or view it on GitHub.
I get a consistent crash with Windows 8.1 and 64bit build. 32bit build produces this; ''AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102'' in the console upon crash. 64bit build doesn't seem to produce anything. On average it takes around 50 seconds to crash, mostly if left to repeat a movie. The above is using the new 1.3beta build from Andrew.
My own builds also crash, much the same as above, but seem to take 5~10 minutes to crash. Also appears to happen mostly on video repeat.
My next step will be disabling videos. If that fixes it then I think we can narrow it down to a video to sound issue. I notice that there is a commented video sound sync issue in code? Will report back with more info when i can.
Okay, update #1. This crash seems to definitely be related to videos. I have tested with 32 bit and 64 bit builds, my own and Andrews 1.3 Beta release. I have also tried different quality videos, higher bitrates/qualities seem to crash a little sooner. The crash doesn't appear to happen if the video is changed often. If a video is left to run repeatedly, the crash will happen, sooner with high quality videos.
Running with no video enabled at all (or disabling via a control button in fe menu), does not appear to crash.
Each time the crash happens, this is output to the console window. AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102 Possible causes as far as I can figure; DirectX backend is incorrect? Debug build? Sound becoming out of sync? Video Cache? Isn't clearing?
I also had similar issue with Luke-Nukem (crash which seems to related to repeating videos..)
Like most multimedia-related problems, it takes random amount of time to crash. In average, about 5-10 repeat then crash.
As Luke-Nukem mentioned, it does not crash if video is changed "before" repeat. Actually, it is quite robust if I constantly change videos (it survived 16 hours of testing)
Maybe it's related to the fact that (as of 1.2.2), if we change the video, the snapshot is shown first, which gives enough time to synchronize video-related whatsoever? (But if current 1.3 Beta does not display snapshot, then maybe it's not...)
Interesting, I installed 1.3 win64 build lastnight and attract crashed again. This time I was setting up a list with sound and video playing in background. I tested this video theory this am and sure enough when the video loop stops attract crashes. Flipping through different games everything is fine but soon as you stop on one screen and let the video finish attract will crash without fail. Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Wednesday, May 21, 2014 2:03 AM, Luke Jones notifications@github.com wrote:
Okay, update #1. This crash seems to definitely be related to videos. I have tested with 32 bit and 64 bit builds, my own and Andrews 1.3 Beta release. I have also tried different quality videos, higher bitrates/qualities seem to crash a little sooner. The crash doesn't appear to happen if the video is changed often. If a video is left to run repeatedly, the crash will happen, sooner with high quality videos. Running with no video enabled at all (or disabling via a control button in fe menu), does not appear to crash. Each time the crash happens, this is output to the console window. AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102 Possible causes as far as I can figure; DirectX backend is incorrect? Debug build? Sound becoming out of sync? Video Cache? Isn't clearing? — Reply to this email directly or view it on GitHub.
Good find. I found a few videos right off that causes attract to crash. Alien Syndrome and altered beast will crash attract when they finish playing. As soon as they finish and pause for a second attract.exe will crash every time. Now, to find out how to fix it. Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Wednesday, May 21, 2014 4:09 AM, checkist84 notifications@github.com wrote:
I also had similar issue with Luke-Nukem (crash which seems to related to repeating videos..) Like most multimedia-related problems, it takes random amount of time to crash. In average, about 5-10 repeat then crash. As Luke-Nukem mentioned, it does not crash if video is changed "before" repeat. Actually, it is quite robust if I constantly change videos (it survived 16 hours of testing) Maybe it's related to the fact that (as of 1.2.2), if we change the video, the snapshot is shown first, which gives enough time to synchronize video-related whatsoever? (But if current 1.3 Beta does not display snapshot, then maybe it's not...) — Reply to this email directly or view it on GitHub.
I see that the Artwork code has been re-written/modified. Particularly to include flags such as video_playing... https://github.com/mickelson/attract/commit/a36582659ebec36b6614db57918ece8218a4029c
Is anyone able to modify their layout to make use of these flags, perhaps to introduce a 1sec pause before repeating, and see if this solves the issue? Unfortunately I am now at work for the next 9 hours, I can't have a fiddle with this myself.
------ Original Message ------ From: "omegaman1" notifications@github.com To: "mickelson/attract" attract@noreply.github.com Cc: "Luke Jones" v8motorhead@gmail.com Sent: 22/05/2014 4:38:49 a.m. Subject: Re: [attract] attract.exe crashes with DEP on (#39)
Good find. I found a few videos right off that causes attract to crash. Alien Syndrome and altered beast will crash attract when they finish playing. As soon as they finish and pause for a second attract.exe will crash every time. Now, to find out how to fix it.
Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Wednesday, May 21, 2014 4:09 AM, checkist84 notifications@github.com wrote:
I also had similar issue with Luke-Nukem (crash which seems to related to repeating videos..) Like most multimedia-related problems, it takes random amount of time to crash. In average, about 5-10 repeat then crash. As Luke-Nukem mentioned, it does not crash if video is changed "before" repeat. Actually, it is quite robust if I constantly change videos (it survived 16 hours of testing) Maybe it's related to the fact that (as of 1.2.2), if we change the video, the snapshot is shown first, which gives enough time to synchronize video-related whatsoever? (But if current 1.3 Beta does not display snapshot, then maybe it's not...) — Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.
thats messed, github didn't notify me of the messages in this thread... i'll try to reproduce myself tonight
ok, i was able to track this down last night and fix it, thanks: https://github.com/mickelson/attract/commit/e0231bde7bf2e45406d644b64a42a39d912641c3
it was introduced with the fix for choppy video in 1.2.2.
Thanks - Keep up the good work. Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Thursday, May 22, 2014 10:40 AM, Andrew Mickelson notifications@github.com wrote:
ok, i was able to track this down last night and fix it, thanks: e0231bd it was introduced with the fix for choppy video in 1.2.2. — Reply to this email directly or view it on GitHub.
Great work Andrew!
Have you done a new build at all? Beta 2 perhaps?
------ Original Message ------ From: "omegaman1" notifications@github.com To: "mickelson/attract" attract@noreply.github.com Cc: "Luke Jones" v8motorhead@gmail.com Sent: 23/05/2014 3:30:12 a.m. Subject: Re: [attract] attract.exe crashes with DEP on (#39)
Thanks - Keep up the good work.
Batty: We're not computers, Sebastian. We're physical. Daryl Hannah as Pris: I think, Sebastian. Therefore I am.
On Thursday, May 22, 2014 10:40 AM, Andrew Mickelson notifications@github.com wrote:
ok, i was able to track this down last night and fix it, thanks: e0231bd it was introduced with the fix for choppy video in 1.2.2. — Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.
can you let me know if it is still crashing for you when DEP is on with the new version 1.3?
I can confirm no issues on 2 machines since this was fixed. On 1/06/2014 4:48 PM, "Andrew Mickelson" notifications@github.com wrote:
can you let me know if it is still crashing for you when DEP is on with the new version 1.3?
— Reply to this email directly or view it on GitHub https://github.com/mickelson/attract/issues/39#issuecomment-44767568.
I can confirm as well. Everything seems to be running solid now.
If Microsoft data execution prevention is turned on, Attract.exe will crash on a consistent basis. I was able to determine this by reading through event logs and crash dumps. The fix is to exclude attract.exe or turn DEP off completely. The former solved the issue for me and now no more crashes. This raises a question though about how the app handles memory management. That is if I understand DEP correctly. I am not a programmer but I do have a lot of IT experience. I know squirrel supposedly handles memory allocation and garbage collection better than lua for example. Curious to read what your take on this is, At least there is a work around for people who have DEP turned on. So, I just wanted to spread the word. Thanks for creating an amazing front-end for us arcade lovers. I am now using attract instead of hyperspin because of its simplicity and flexibility. Looking forward to your future updates and enhancements.