<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Segfault in xf86DestroyI2CDevRec"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93675#c11">Comment # 11</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Segfault in xf86DestroyI2CDevRec"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93675">bug 93675</a>
              from <span class="vcard"><a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> <span class="fn">Kevin Brace</span></a>
</span></b>
        <pre>(In reply to Kyle Guinn from <a href="show_bug.cgi?id=93675#c10">comment #10</a>)

Hi Kyle,

<span class="quote">> > If you take out xf86DestroyI2CDevRec API call after 2 calls to
> > xf86I2CProbeAddress API call, the problem seems to go away (I am not sure if
> > this is okay. If it is not, let me know.).
> > 
> > _____________________________________________________________________________
> > 
> >     if (xf86I2CProbeAddress(pVia->pI2CBus3, pDev->SlaveAddr)) {
> >         pDev->pI2CBus = pVia->pI2CBus3;
> >     } else if (xf86I2CProbeAddress(pVia->pI2CBus2, pDev->SlaveAddr)) {
> >         pDev->pI2CBus = pVia->pI2CBus2;
> >     } else {
> > //      xf86DestroyI2CDevRec(pDev, TRUE);
> >         return;
> >     }

> Yes, that's the same offending line that I found.  Removing the
> xf86DestroyI2CDevRec call should fix it (haven't tried it myself) but it
> will result in a memory leak (Create without a matching Destroy).  That's
> why I decided to patch xf86DestroyI2CDevRec to handle this better.</span >

Do you have ideas on how this bug can be fixed without having to patch xorg
(like what your patch does)?
Over at <a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics"
   href="show_bug.cgi?id=91966">Bug 91966</a>, I recently uploaded patches that will scan for the existence
of VT1632A regardless whether or not it is actually hooked up.
As you saw from the source code snippets I showed, currently VT1632A is scanned
only when P4M800 Pro and related chpsets are used. 
The patches I uploaded will let OpenChrome scan several I2C buses to figure out
what is connected.
This became necessary because the bug reporter's system has a DVI-I connector
(a DVI connector with DVI and VGA coming out, but shares the I2C bus between
the two).
Unfortunately, he was having strange freezes with the second I2C bus
(OpenChrome calls it I2C bus 2).
I am wondering if the instability the bug reporter reported is related to what
you called "Create without a matching Destroy."

Regards,

Kevin Brace</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>