<html>
    <head>
      <base href="https://bugs.webkit.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span> changed
          <a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - WebKit2.WebContext register_uri_scheme does segfault"
   href="https://bugs.webkit.org/show_bug.cgi?id=116672">bug 116672</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>mcatanzaro@igalia.com
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - WebKit2.WebContext register_uri_scheme does segfault"
   href="https://bugs.webkit.org/show_bug.cgi?id=116672#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - WebKit2.WebContext register_uri_scheme does segfault"
   href="https://bugs.webkit.org/show_bug.cgi?id=116672">bug 116672</a>
              from <span class="vcard"><a class="email" href="mailto:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
        <pre>(In reply to Philip Chimento from <a href="show_bug.cgi?id=116672#c2">comment #2</a>)
<span class="quote">> What's going wrong here is that the default WebContext object is destroyed
> in an atexit() handler. When that happens, the GDestroyNotify function
> passed to register_uri_scheme() is called, but at that point the Python or
> JS runtime has already been shut down, so it segfaults.

> A library should definitely not register any atexit() handlers.</span >

Easier said than done. :(

<span class="quote">> Probably it
> should be OK to not destroy the default WebContext, since the memory will be
> reclaimed at the end of the process anyhow.</span >

Problem is a mismatch between C++ best-practices, and GObject.

C++ allows static objects. Best practice is to only ever store trivially-destructible types into static objects. If you store something that's not trivially-destructible, then its destructor will be run in an exit handler. In WebKit cross-platform code, we ban exit-time destructors because they get executed in nondeterministic order on Windows.

But in the GTK/WPE-specific code, we've found cases where it's unavoidable. <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [SOUP] SoupCookieJar is never released (resulting in sqlite temp files lying around)"
   href="show_bug.cgi?id=166029">Bug #166029</a> comes to mind. C++ best practice is to leak the object to avoid an exit time destructor, but GObject classes expect to be disposed and finalized and do important things besides free memory when disposed/finalized. In this case, that was to close database handles. It could also be to shut down network connections, etc. (We also have a couple manual exit handlers too, but this isn't one of those.)

So if we want to leak the default web context, we have to make sure it's safe to do so. That means checking its dispose/finalize, and the destructors of all objects in its priv struct, to make sure each and every one of them is safe to skip. And then predicting the future to ensure that no destructors are ever added that would be unsafe to skip. It's a really hard problem. I know for starters that we'll run into problems because the default WebProcessPool won't be destroyed, and that is leak-checked, so you'll get a big warning in debug builds, for instance.

So not a simple problem at all. Not at all....</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>