[FFmpeg-user] Zeranoe Windows builds spiking CPU to 100% randomly

[Kyle Schwarz]

Hi,

On 7/12/2012 2:52 AM, Andy Sheen wrote:
> Roger Pack wrote on Wed 11 Jul at 21:54 UK time
>>>> It would be interesting to know why pthreads fails but win32threads
>>>> succeeds.  Also I assume that if you compile it with w32threads
>>>> enabled and use -threads 0 I presume it does use all the available
>>>> cores?
>>>
>>> I agree it would be interesting - and even more interesting why the
>>> commit the git bisect causes the issue (and only with the avconv build
>>> and not the ffmpeg from the same source tree).
>>
>> That commit (if I'm thinking of the right one) set the thread default
>> to "0", which means "auto detect" (i.e. use all the cores available),
>> so basically, it was forcing multi-threaded behavior by default.  Why
>> avconv and not ffmpeg, I have no idea, but my guess is that you'd see
>> the same behavior with builds previous to that (and have to search for
>> a new "offending commit") if you passed them the -threads 0 parameter.
>>
>
> but I'm specifying -threads 8 in all my command lines, so there should
> be no difference.
>
>>> I'm at a bit of a loss to
>>> debug further - monitoring the process changes the behaviour - I don't
>>> think gdb will do anything useful (I installed mingw gdb and it still
>>> doesn't recognise the file - I guess as it's a 32bit build of mingw...)
>>> as you can't CTRL-C the process when it is in this state.
>>
>> Maybe you could build a 32-bit build (does it exhibit the same
>> features), or possibly the mingw-w64 peeps have a 64 bit gdb
>> available, I haven't checked [1].
>>
>
> Can't easily see a 64-bit gdb, yes, I can build a 32 bit version and see
> if the same problem occurs, but it does point to a race condition in the
> wingw implementation of pthreads at the moment.

I'm unable to reproduce this error. It could be because I'm not on my 
powerful desktop, or it could be something else.

Could you give me the most basic command line that still produces the 
issue with my latest builds (299387e)?

The reason I use pthread/winpthreads instead of w32thread is because 
many more packages on Linux support pthread then do w32thread. I also 
believe the code base to be stable and a good thread management solution.

You can also compile gdb with the toolchain you used to compile FFmpeg, 
if your interested.

Best regards,
   Kyle Schwarz (Zeranoe)