[FFmpeg-trac] #10210(avcodec:new): On Windows with x86 build, calling avcodec_send_packet does not free FPU registers

[FFmpeg]

#10210: On Windows with x86 build, calling avcodec_send_packet does not free FPU
registers
-------------------------------------+-------------------------------------
             Reporter:  Kevin        |                    Owner:  (none)
  Coulombe                           |
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  avcodec FPU  |               Blocked By:
  fld ST0 x87                        |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Kevin Coulombe):

 Replying to [comment:6 Balling]:
 > Also, I am still not convinced emms_c should not be called by Windows or
 Linux kernel on exit (or y apps on start). After all most of handles close
 and so does the heap memory. Though I think handles on files are not
 autoclosed, there was such a bug inside Chrome...

 I'm not sure I understand this.

 The demo app calls into avcodec directly through cross dll function calls
 in cdelc calling convention. Then when it recovers control, the registers
 are used up and there isn't much Windows or Linux can do to clear those
 registers.

 The compiler of the hosting application could add the instructions to do
 it, but cdecl specifically says it's the callee's responsibility. So both
 the VC++ compiler and the dotnet runtime assume that those registers have
 been freed by the callee and don't touch them after a function call.

 >Is that inline assembly bug? Why do not you think is not a bug of what
 you used to compile .dlls? It appears you used 14.29, which is still
 Visual Studio 2019.

 I built it with VS 2019 because the build scripts I got break down with VS
 2022 now being x64 (different program files dir). But [comment:4 Seb]
 seems to have the same issue with VS2022. I'd be very surprised if we were
 in front of a Microsoft compiler bug.

 > It is corrupt...

 As for the image being corrupt, the decoder should still respect calling
 conventions. We receive the payload from physical cameras that can get
 pretty creative with their encoding...
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10210#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker