View Full Version : r858 crashes
audyovydeo
21st May 2008, 00:18
something between 852 and 858 borked something related to threads :
single-core = OK
coreduo+threads auto = crash after 18 frames
coreduo+ threads 1 = OK
851 was fine.
XP SP2 32bits.
r858 from bob0r's site
J_Darnley
21st May 2008, 01:11
I think it was r852. I also experience crashes with revisions > 851 unless I reverse the deblock_luma_intra_mmx commit. If I build the revisions after 851 with this diff (http://git.videolan.org/?p=x264.git;a=commitdiff_plain;h=1451b1285b37e54209c2216a7eab6f47ed2a0abd) reversed then it all goes fine. Dark Shikari said that this was very strange as that commit should not affect threading.
bob0r
21st May 2008, 03:12
Confirmed.
x264 rev 852 crashes on Windows with threads and deblock.
So basically every encode.
pengvado is aware of the problem, and all we can do is pray to the stars he can and will fix the problem.
Dark Shikari
21st May 2008, 03:35
Fixed. Pengvado found a case in which deblocking wasn't protected by x264_stack_align, which is required on Windows when pthreads is used. Linux and non-threaded situations were not affected.
r859 fixes it.
DeathTheSheep
23rd May 2008, 01:15
Wow, I thought it was something a patch did and got quite annoyed when threading killed it. Then again, I went from 851 to 858 in one swing, so...yeah.
Glad this thing was sorted out. Gosh, alignment... I never fully understood what alignment even is (or AltiVec), much less what the heck it does and why many a revision of x264 were spent "aligning" things. It makes the code less easy to understand, for one. And lake thereof caused this crash, for another... :p
Dark Shikari
23rd May 2008, 01:20
Wow, I thought it was something a patch did and got quite annoyed when threading killed it. Then again, I went from 851 to 858 in one swing, so...yeah.
Glad this thing was sorted out. Gosh, alignment... I never fully understood what alignment even is (or AltiVec), much less what the heck it does and why many a revision of x264 were spent "aligning" things. It makes the code less easy to understand, for one. And lake thereof caused this crash, for another... :p
Let's say the memory address to an array is 8000 and we need to do aligned SSE loads (movdqa == 16 byte load) from it. This is fine, because 8000 is divisible by 16, which means its aligned.
But let's say our memory address is 8003.
Now its not aligned.
We call movdqa to load from it... and the program crashes.
On x86 processors, only SSE loads have to be aligned; on most other processors all loads have to be aligned to the size of the variable being loaded. So for example, if I load a 32-bit value (4 bytes) it has to be aligned to at least 4.
LoRd_MuldeR
23rd May 2008, 01:21
I never fully understood what alignment even is
http://en.wikipedia.org/wiki/Data_structure_alignment :p
Inventive Software
23rd May 2008, 06:05
Research assembly programming the 68000 to get an idea of strict alignment. :)
DeathTheSheep
23rd May 2008, 07:06
Wee... all right, I get it, I'll try to align crap from now on. Sheesh, I aligned the stuff in the new patch at least... on my computer. :)
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.