Crash/reboot during encode

[jpsdr]

I've an issue with new x264 version i've build.
After encoding around 3000 frames in the 1rst pass, apparently x264 crash making the PC reboot. Compile was made with a simple "make", not fprofiled.
So, as i was already explained for a similar case, i've build a debug version, and use dbg. x264 crash immediatly this time, encode didn't even started !
Result is :

I:\Porco Rosso>gdb x264.exe
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from I:\Porco Rosso\x264.exe...done.
<o_Chapters_x264.txt --threads 0 --thread-input --output NUL Porco_BR.avs
(gdb) run
Starting program: I:\Porco Rosso\x264.exe --profile high --preset placebo --tune
animation --pass 1 --bitrate 31518 --stats Porco_BR.stats --level 4.1 --vbv-max
rate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --mvrange 511 --ref 4
--bframe 3 --slices 4 --b-pyramid strict --open-gop --bluray-compat --fade-compe
nsate 0.8 --subme 7 --me umh --aq-mode 3 --aud --nal-hrd vbr --colorprim bt709 -
-transfer bt709 --colormatrix bt709 --videoformat ntsc --sar 1:1 --qpfile Porco_
Chapters_x264.txt --threads 0 --thread-input --output NUL Porco_BR.avs
[New Thread 260.0xf0]
[New Thread 260.0xfc]
warning: DllMain: hModule=0x80000000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

[New Thread 260.0x7c8]
[New Thread 260.0x4b4]
[New Thread 260.0x580]
[New Thread 260.0x7e0]
[New Thread 260.0x2dc]
[New Thread 260.0x7b8]
[New Thread 260.0xf4]
[New Thread 260.0x5d4]
[New Thread 260.0xf8]
[New Thread 260.0x70c]
[New Thread 260.0x6ec]
[New Thread 260.0x3e0]
avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)

Program received signal SIGSEGV, Segmentation fault.
0x0000000077d70007 in OpenFileMappingW ()
from H:\WINDOWS\system32\kernel32.dll
(gdb) bt full
#0 0x0000000077d70007 in OpenFileMappingW ()
from H:\WINDOWS\system32\kernel32.dll
No symbol table info available.
#1 0x0000000000000000 in ?? ()
No symbol table info available.

So... help again...

[LoRd_MuldeR]

User-space applications cannot make your whole system crash or reboot or show a BSOD, on modern operating systems - under normal circumstances.

If this happens anyway, it indicates a more serious problem with your system, such as overheating, bad RAM modules or a driver bug. x264 probably only happens to trigger the "real" problem.

Except when OpenCL is involved, I would exclude driver issues with x264. So run memtest86 and Prime95 to stress test your system...

(As for OpenCL: I noticed once that the video driver would crash when the x264 process is aborted with Ctrl+C. Fortunately, Windows was able to recover and restart the video driver)

[EDIT]

BTW: The info "No symbol table info available" in your stack trace either indicates you actually did not use a Debug build - or it crashed somewhere "outside" of x264.

In the latter case, it probably crashed in Avisynth or (more likely) in one of the Avisynth filters/plugins involved! So how does your AVS script look? Does that script work in, e.g., VirtualDub?

I would try to open that very same AVS file in VirtualDub and let it play through all the way to end. Then see what happens...

[jpsdr]

My avisynth script :

SetMemoryMax(192)
AVISource("Porco.avi",False,"YV12")
SetPlanarLegacyAlignment(True)


Yes, it's perfectly opened in VDub64, and i've just started the play.
With --enable_debug, my build is around 5,2MB, without it, my build is around 1,6MB, and, i've used the 5,2MB build i've made.

[EDIT] :
Play is actualy at frame 5000, wich is higher than the moment the encode crashed/rebooted.

[jpsdr]

More tests.
First, crash/reboot occurs very quickly, less than 5 minutes after encode starts.

- Memtest : 2 passes, results ok.
- Prime95, tested 15 minutes of both FFT tests and blend test. No issues.

My build was a custom build, tested from master/clean build, exactly the same result.

I've tried to encode avi directly, result almost the same, just less threads :

I:\Porco Rosso>gdb x264.exe
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from I:\Porco Rosso\x264.exe...done.
<o_Chapters_x264.txt --threads 0 --thread-input --output NUL Porco.avi
(gdb) run
Starting program: I:\Porco Rosso\x264.exe --profile high --preset placebo --tune
animation --pass 1 --bitrate 31518 --stats Porco_BR.stats --level 4.1 --vbv-max
rate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --mvrange 511 --ref 4
--bframe 3 --slices 4 --b-pyramid strict --open-gop --bluray-compat --fade-compe
nsate 0.8 --subme 7 --me umh --aq-mode 3 --aud --nal-hrd vbr --colorprim bt709 -
-transfer bt709 --colormatrix bt709 --videoformat ntsc --sar 1:1 --qpfile Porco_
Chapters_x264.txt --threads 0 --thread-input --output NUL Porco.avi
[New Thread 1724.0x6c4]
[New Thread 1724.0x6c8]
warning: DllMain: hModule=0x80000000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

avs [info]: trying AVISource...
Program received signal SIGSEGV, Segmentation fault.
0x0000000077d70007 in OpenFileMappingW ()
from H:\WINDOWS\system32\kernel32.dll
(gdb) bt full
#0 0x0000000077d70007 in OpenFileMappingW ()
from H:\WINDOWS\system32\kernel32.dll
No symbol table info available.
#1 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)

[nhakobian]

Have you attempted to use one of the official builds to test? Its possible that you are using a set of compilers/assemblers that does something odd with the x264 source or that of one of the accompanying libraries.

I would also test it with a source other than an AVS source. If it still happens, it might help you narrow down where the issue is occuring. (Of course, if it doesn't happen it might not help much.)

Edit: I just realized you had tried both and it still happens. It helps if I read each post thoroughly >.<.

If no one else has this issue, its leading towards something odd about your system. Perhaps an odd memory issue? Maybe something messed up in one of the windows system files (unlikely). Maybe a driver that is misbehaving (also unlikely if this is the only program with issues, but not impossible).

Many times these types of errors are difficult to trace.

[Sparktank]

Is your AVI source clean?
Does this happen with other sources?

Have you done a complete (not quick) virus/malware scan recently?

Try cleaning the registry (only after doing a complete v/m scan).

Use "OldTimer's List" to scan for anything out of the ordinary.
Download here (http://www.geekstogo.com/forum/files/file/398-otl-oldtimers-list-it/)
Guide here (http://www.geekstogo.com/forum/topic/2852-malware-and-spyware-cleaning-guide/) (read all of it; lots to read)

OTL is a handy tool to find out-of-place items and even files created in the past X days to see if anything was silently installed or even chagned.

Lastly, have you tried to reinstall AVS?

[jpsdr]

The PC i use to make my video encode is a standalone dedicated only to this. It's not and will never be connected to internet, so it doesn't have anything related to internet (no antivirus, firewall, etc...). All the eventualy update of softwares is made by usb comming from my standard PC which have everything needed.
No re-install or anything.
But, last time i had this issue, it was solved by switching from fprofiled build to no fprofiled build. The build which make the PC reboot was no fprofiled. I've made fprofiled build, and... instead of rebooting after 5 minutes in the 1rst pass, apparently the whole encode (the 2 pass), went fine.
I don't have others avi at hand for the moment, and it's a build with just the new release, so, i can't say if it's happening with the other sources.
But as for now i've something which seems to work (even if i don't know why), i think issue is resolved. And in last resort, i can switch back to XP32 (32 bit no fprofiled version didn't crash), i have 40% speed up under XP64, but slower is better than nothing...
I use gcc473 and gcc47x libpack from komisar's site. I use yasm v1.20. I follow the doom10 tutorial for compiling, and as i don't have what needed (and don't use it), i compile with --disable-opencl.

[MasterNobody]

jpsdr
Try the latest version (there was one more hot fix today). Dunno about reboot but at least it should fix crash under gdb at the start of encoding.

[Stereodude]

Stress test your PC with AIDA64. I've found It will find stability issues that other tools miss.

[jpsdr]

I've noticed yesterday evening the crash fix under gdb. I've rebuild all my versions (in fprofiled mode), and also build a debug x64 version, tested under gdb and no crash at the start, neither after 7000 frames also.
I'll test AIDA64, thanks.
[EDIT] Is the trial version of AIDA64 enough ? Otherwise, i'll not waste time trying.

[Stereodude]

I'll test AIDA64, thanks.
[EDIT] Is the trial version of AIDA64 enough ? Otherwise, i'll not waste time trying.
Yes, the trial can run the System Stability Test.

You're looking for this screen / test (http://www.aida64.com/files/screenshots/sst1.png). I've found it useful to do several runs with different options checked each time. Like 24 hours of CPU + FPU, 24 hours of CPU + FPU + cache, and 24 hours of CPU + FPU + cache + system memory. If it passes all 3 of the 24 hours tests I mention your CPU + mobo + RAM subsystem is solid and stable.

[jpsdr]

Ok, thanks.

[jpsdr]

I've made the 3 suggested tests, everything went fine.

[Stereodude]

Well, I'd guess your crash/reboot is not related to an instability in the hardware of your PC. I'm not sure where else to point you though.

[jpsdr]

For now, with the new version i've compiled, including the fix MasterNobody talked about, the encode where the crash occured went fine. I've not done any other encode since. Maybe it was related to the issue fixed in the last hot fix. At least, i know my hardware is fine. And, for now, issue seems fixed.

[sneaker_ger]

At least, i know my hardware is fine.

The bug in the hardware/drivers/OS still exists, it's just that the new build does not trigger it anymore.