On 11/15/2017 11:01 PM, Carl Eugen Hoyos wrote: > 2017-11-16 2:52 GMT+01:00 James Almer <jamr...@gmail.com>: >> On 11/15/2017 10:35 PM, Carl Eugen Hoyos wrote: >>> 2017-11-16 2:29 GMT+01:00 James Almer <jamr...@gmail.com>: >>> >>>> The OP configure line is a massive dump of pointless >>>> "--disable" options typical from Gentoo builds, >>> >>> Good to know we agree on something. >>> >>>> so i didn't even bother looking at it for specific things. >>> >>>> And now that i look at yours they are completely different >>>> as well >>> >>> And I thought I spent several hours today only to allow you >>> to reproduce a crash to ease testing by providing the >>> necessary configure switches. >>> They are of course identical to what the op provided, do >>> you really suggest I added those stupidities for fun? >> >> Yours was "--enable-small --toolchain=hardened --disable-avx", >> and only the latter is in the OP configure line. They didn't use >> neither small or hardened. > > So you are still saying that I added the options for fun?
No, i didn't say or even imply that. What i said is what's written in that email: Since the two command lines seemed pretty different, then perhaps said options were not related to the crash and it's a target dependent issue. Again, i didn't intend to offend you in any way whatsoever. > (Thank you, as said it did take significantly more than > an hour to find them.) > > The op used an equivalent for both small and hardened in > his configure line that imo is not supported by us, I found > a supported configure line that has the same effect on > config.mak and the resulting binary. > > I knew that you were able to solve the riddle without > the configure line but I still believe it makes sense > for you to also being able to test a fix. > > I do not understand why you wrote you cannot reproduce > when you did not even try to. Because at no point i assumed the configure line you or the OP used could be needed to reproduce a crash like this. A wrong assumption in retrospect, as STRIDE and av_malloc alignment can be affected by configure options, and stack alignment (as it was the issue here) by compiler options. So since i was testing with a different OS than you two, i figured it was pretty much target dependent and decided to send the patch stating it was untested. > Since the issue is not easily reproducible with clang, I > still wonder if it is reproducible on Windows. gcc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all -fPIE -c -o /tmp/ffconf.OTilhXct/test.o /tmp/ffconf.OTilhXct/test.c gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.OTilhXct/test.exe /tmp/ffconf.OTilhXct/test.o F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '-z' F:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information collect2.exe: error: ld returned 1 exit status C compiler test failed. configure can't even succeed with --toolchain=hardened on mingw-w64, so looks like i wouldn't have been able to reproduce it to begin with. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
