Hi David, that crash looks like one I get now and again, I believe font related.
Have you tested with the Firefox build that OS4USER mentioned? Perhaps with the AVX enabled kernel? You can get a list of CPU capabilities with this program, http://hobbes.nmsu.edu/download/pub/os2/util/misc/cpuinfo.zip
If needed, I could build FFmpeg with AVX disabled. Be nice to know which function it is crashing in too.
If you sent me the MAP file for AVCODE65.DLL it would be a piece of cake to find the failing routine. We have the trap location ...
I don't have the map files for the Netlabs build of FFmpeg. I can build one after work if David is interested in testing.
As I said, the "something" not aligned correctly seems to be a 32-byte (AVX) constant (read only) directly encoded in the code segment.
Where do I find the code for AVCODE65.DLL ?
I looked at:
https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec
but there is no assembler code there, only plain "C" code. Which makes me wonder why we do not use plain "C" code and let GCC do all the gory stuff like data alignment (once GCC aligns SSE and AVX data the way it should ...). I would expect a good "C" compiler to automatically parallelize data accesses (and therefore making good use of the SIMD capabilities of the CPU). At least the Intel compiler does that ...
Start here for the assembler code,
https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcodec/x86 there's also some in libavutil.
As for using plain C, building FFmpeg with --disable-assembler results in code that is so slow it is unusable. GCC is quite crappy at optimizing compared to hand written assembly by experts.
Also need assembler to dynamically optimize based on CPU, which simd instructions it supports, how many registers are available, even things like whether using CMOV is a good idea or if it is a really slow implementation.
GCC is still calling the assembly functions so I guess that is where alignment comes in.
By the way: since the OS/2 kernel does not support AVX, wouldn't it be better to NOT build with AVX capability in general ?
I don't have AVX (only SSE) and therefore I am not affected but we can already see that with more modern systems that do support AVX or even AVX2 (with 512-bit registers), we now run into a whole lot of problems with AVX (data not properly aligned, no OS support for saving away AVX registers on a thread switch, with exception of OS/4 kernel).
Note: OS/2 does have support to save and restore SSE registers on a thread swith.
Lots of code uses AVX assembler and dynamically loads it if the OS and CPU support it. Firefox's JIT, libvpx, libx264, even flac just of the top of my head. Most I don't have control over.
It does seem to help using a newer GCC. Hopefully when Bitwise moves to GCC 8 (soon), things will improve.
For me, OS/2 is falling more and more apart.
Lars
