<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Ok, good news, I'm back on the faulty machine and after a
      complete cleanup and recompilation it seems like the bug was
      related to a dirty build system. My bad...</p>
    <p>At least Rémi fixed another bug thanks to this ...<br>
    </p>
    <div class="moz-cite-prefix">On 26/02/2020 23:59, Quentin Chateau
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACJnN61UJO030TYyK81tqFhDmpS3Gv-aP-W1-mq08s29SfwiWg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">Le mer. 26 févr. 2020
            à 20:47, Rémi Denis-Courmont <<a
              href="mailto:remi@remlab.net" moz-do-not-send="true">remi@remlab.net</a>>
            a écrit :<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">Le keskiviikkona 26.
            helmikuuta 2020, 16.34.09 EET Quentin Chateau a écrit :<br>
            > Thanks for the hindsight, I dug further:<br>
            > <br>
            > vlc_cond_timedwait is called, and so is
            pthread_cond_timedwait. The<br>
            > issue happens when the deadline parameter is in the
            past: when this<br>
            > happens, pthread_cond_timedwait does not act as a
            cancellation point<br>
            > anymore...<br>
            <br>
            pthread_cond_timedwait() and pthread_cond_wait() are
            *always* cancellation <br>
            points. The deadline does not matter.<br>
          </blockquote>
          <div><br>
          </div>
          <div>That's what I though as well. Though it seemed that it
            did not act as a cancellation point. I am not able to
            reproduce on a different machine right now. I'll have to
            double check tomorrow on the machine that I had the bug on.</div>
          <div> <br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <br>
            vlc_cond_timedwait() and vlc_cond_wait() are likewise
            supposed to always be <br>
            cancellation points. By my count, there are 21 outstanding
            vlc_cancel() call <br>
            sites still depending on that behaviour.<br>
            <br>
            Right now, there is a bug for which I just sent a patch<br>
          </blockquote>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <br>
            > In my case deadline happens to be in the past because<br>
            > ThreadDisplayPicture keeps failing (due to one of my
            video filters<br>
            > failing on the last frame)<br>
            > <br>
            > I could not find this behavior in the pthread
            documentation, but it<br>
            > seems to be the case anyway. Do you think that we need
            to:<br>
            > <br>
            >  1. Fix vlc_cond_timedwait so it will check for
            cancellation if the<br>
            >     deadline is in the past<br>
            <br>
            I don't think that that's a feasible option.<br>
            <br>
            For a start, I couldn't find that bug in those
            circumstances. I did find a bug <br>
            with the same symptions in different circumstances though,
            see patch.<br>
            <br>
            And then, even if the bug were there where I could not see
            it, there are no <br>
            ways to determine that the deadline is in the past, as that
            changes <br>
            asynchronously.<br>
            <br>
            >  2. Acknowledge the fact that vlc_cond_timedwait is not
            always a<br>
            >     cancellation point and fix the issue higher in the
            stack, either in<br>
            >     vout_control_Pop, or similarly to the patch I sent,
            directly in Thread<br>
            <br>
            You can't do that either, or at least not yet. Not when we
            still have 21 or so <br>
            code paths depending on it.<br>
            <br>
            -- <br>
            Rémi Denis-Courmont<br>
            <a href="http://www.remlab.net/" rel="noreferrer"
              target="_blank" moz-do-not-send="true">http://www.remlab.net/</a><br>
            <br>
            <br>
            <br>
            _______________________________________________<br>
            vlc-devel mailing list<br>
            To unsubscribe or modify your subscription options:<br>
            <a href="https://mailman.videolan.org/listinfo/vlc-devel"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://mailman.videolan.org/listinfo/vlc-devel</a></blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
<a class="moz-txt-link-freetext" href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre>
    </blockquote>
  </body>
</html>