<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters." href="https://bugs.freedesktop.org/show_bug.cgi?id=98172#c44">Comment # 44</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters." href="https://bugs.freedesktop.org/show_bug.cgi?id=98172">bug 98172</a> from <a class="email" href="mailto:shinji.suzuki@gmail.com" title="Suzuki, Shinji <shinji.suzuki@gmail.com>"> Suzuki, Shinji</a> <pre>> screen->fence_reference(screen, &fence, NULL); > > is always thread-safe with a local variable fence, That case is thread-safe not because the variable is local but because concurrent execution is not possible because the variable is local. :) >Since the fence signalled before the first waiter returns, I'd say that's at least sort of correct. :) I agree that it is 'sort of' correct. But a program that is very particular about fence being reached within set time-out period or not will misbehave. >=> r600_fence_reference and st_client_wait_sync continue working > with the fence object memory, which was already freed by thread > 1. I see that, since so->fence is duplicated at the beginning of the function, destruction of the fence object would never happen in the block covered by cmpxchg. If it ever happens then that would be by the 'unref' before the function exit. > Did you run into any particular problem with my latest patch? I run my app for while with your patch minus the locking during reference duplication and observed no crashes. I'm sufficiently confident that yours is correct and my remaining concern is mostly about lock contention plus the feeling that solution via serialization of unref-ops blurs the nature of the problem that is inherent in the sock code. There is also a concern that if you acquire lock during reference duplication here, someone who study this part of the code later on may think that locking is necessary operation and do the same even though reference duplication is, as far as I can see, lock-free operation. That would further increase contention. With all that said, I don't mind you applying your patch to the master. I believe it is correct. Your decision must take priority because I think you are in position to devote much more time and energy in improving mesa than I can contribute. In addition, I would not be enough confident about my cmpxchg solution until I write tens of unit-tests to be run days and weeks continuously in various environments, which I perhaps will not have time for.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>