[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #49 from Suzuki, Shinji --- (In reply to Marek Olšák from comment #47) > What was wrong with the initial mutex idea? I think the solution in comment > 22 is sufficient to close this bug. I did not like added

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #48 from Marek Olšák --- I've sent my patches that fix this to mesa-dev. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #47 from Marek Olšák --- What was wrong with the initial mutex idea? I think the solution in comment 22 is sufficient to close this bug. -- You are receiving this mail because: You are the QA Contact for the bug.

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #46 from Michel Dänzer --- (In reply to Suzuki, Shinji from comment #44) > >=> r600_fence_reference and st_client_wait_sync continue working > > with the fence object memory, which was already freed by thread >

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #45 from Suzuki, Shinji --- > feeling that solution via serialization of unref-ops blurs the nature of the > problem that is inherent in the sock code. This concern can perhaps be obviated by inserting an

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #44 from Suzuki, Shinji --- > screen->fence_reference(screen, , NULL); > > is always thread-safe with a local variable fence, That case is thread-safe not because the variable is local but because concurrent

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #43 from Michel Dänzer --- (In reply to Suzuki, Shinji from comment #41) > "screen->fence_reference(screen, , NULL); > is thread-safe if calls are serialized otherwise not thread safe". Not quite.

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #42 from Suzuki, Shinji --- Sorry for the clutter. Timeout is not handled in the previous attempt. (The use of the shared completion flag seems to have potential synchronization problem because a waiter can

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #41 from Suzuki, Shinji --- I think now I have better understanding of the problem we are dealing with here. >Not thread safe (race condition on so->fence): > screen->fence_reference(screen, >fence, NULL);

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #40 from Suzuki, Shinji --- Sorry I misunderstood your question and thought that you are asking if my modification works or not. Your patch should work if mine works because yours has tighter serialization.

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #39 from Michel Dänzer --- Well, it seems to be the best test case we have so far, and it's the most relevant one for this bug report. :) -- You are receiving this mail because: You are the assignee for the bug.

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #38 from Suzuki, Shinji --- As you saw, now I'm running my app without locking on the first block of code but with locking on the second. So far so good. But my application is streaming video processing. I

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 Michel Dänzer changed: What|Removed |Added Attachment #127267|0 |1 is

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #36 from Suzuki, Shinji --- Michel-san, thank you for elaboration. Maybe this discussion continues because I have failed to express my question clearly. What I'm wondering is that if the following section

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #35 from Marek Olšák --- (In reply to Michel Dänzer from comment #34) > (In reply to Suzuki, Shinji from comment #31) > > Why is this patch rejected? > > Because it'll have to be rebased on top of the updated patch

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #34 from Michel Dänzer --- (In reply to Suzuki, Shinji from comment #31) > Why is this patch rejected? Because it'll have to be rebased on top of the updated patch 1. > Now I'm revisiting your patch. Do we need

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #33 from Suzuki, Shinji --- (In reply to Marek Olšák from comment #32) > Reference counting is thread safe, but the assignment in the sync obj > structure itself isn't. So you need a mutex. I see no

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #32 from Marek Olšák --- Reference counting is thread safe, but the assignment in the sync obj structure itself isn't. So you need a mutex. -- You are receiving this mail because: You are the assignee for the bug.

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #31 from Suzuki, Shinji --- (In reply to Michel Dänzer from comment #30) > (In reply to Suzuki, Shinji from comment #29) > Yes, that'll be patch 2, à la > https://patchwork.freedesktop.org/patch/115220/ . :)

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #30 from Michel Dänzer --- (In reply to Suzuki, Shinji from comment #29) > BTW, st_check_sync and st_client_wait_sync() seem identical except for the > existence of flags and timeout. Should they be merged? Yes,

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #29 from Suzuki, Shinji --- Sorry. I looked at only your latest comment when I replied previously because I read it in email. You are absolutely right. fence_finish() MUST run concurrently even if they

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #28 from Suzuki, Shinji --- Yes. I agree with you that we can do without per-sync-object if we allow all waiters enter fence_finish() freely. With that said, per-sync-object mutex has another benefit of

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #27 from Michel Dänzer --- Note that if we allow concurrent fence_finish calls, I don't think we need a per-sync-object mutex. -- You are receiving this mail because: You are the assignee for the bug. You are

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #26 from Michel Dänzer --- (In reply to Marek Olšák from comment #24) > Hm. Probably none. Actually, I think there are: E.g. consider one thread calling glClientWaitSync with a non-0 timeout, blocking for some

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #25 from Suzuki, Shinji --- Thank you for your comments. Patches attached here by me are against 11.2. I'll base on maser when posting diff to the mailing list. -- You are receiving this mail because: You

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #24 from Marek Olšák --- Hm. Probably none. The patch looks good. BTW, the patch won't apply on master, because the fence_finish function is slightly different there. -- You are receiving this mail because: You

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #23 from Suzuki, Shinji --- (In reply to Marek Olšák from comment #22) > It would be better to call fence_finish while not holding the mutex. For >mtx_unlock(>mtx); > >if

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #22 from Marek Olšák --- It would be better to call fence_finish while not holding the mutex. For example: mtx_lock(>mtx); /* If the fence doesn't exist, assume it's signalled. */ if (so->fence) { struct

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #21 from Suzuki, Shinji --- Created attachment 127366 --> https://bugs.freedesktop.org/attachment.cgi?id=127366=edit Per sync-object mutex. Redundant 'else' and setting of StatusFlag are eliminated. --

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #20 from Suzuki, Shinji --- Thank you. That's certainly easier to read. Also, now I see that so->b.StatusFlag needs to be set to True only when so->ference is set to NULL in either st_check_sync() or

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #19 from Michel Dänzer --- (In reply to shinji.suzuki from comment #16) > Created attachment 127317 [details] [review] > Arbitration on so->fence through per sync-object mutex. One minor comment below, otherwise

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #18 from shinji.suz...@gmail.com --- > Looks like glDeleteSync directly calls (or is a macro of?) I thought that was the case because I got this stack trace; (gdb) where #0 st_delete_sync_object (ctx=0x863890, obj=0x7fffe8001320)

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #17 from shinji.suz...@gmail.com --- I need to take my words back. > dtor should be called only by the thread that eliminated the last reference. Looks like glDeleteSync directly calls (or is a macro of?) st_delete_sync_object. If

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #16 from shinji.suz...@gmail.com --- Created attachment 127317 --> https://bugs.freedesktop.org/attachment.cgi?id=127317=edit Arbitration on so->fence through per sync-object mutex. -- You are receiving this mail because: You are

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #15 from shinji.suz...@gmail.com --- Created attachment 127316 --> https://bugs.freedesktop.org/attachment.cgi?id=127316=edit Arbitration on so->fence based on Michel-san's patch -- You are receiving this mail because: You are the

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #14 from shinji.suz...@gmail.com --- I've ben running tests with changes derived from your patch, with and without random sleeps to give some shake-ups to execution order with, and have seen no crashes so far. The differences from

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #13 from shinji.suz...@gmail.com --- > So the second fence_reference call will find so->fence == NULL and do nothing. Thank you. I failed to see that fence_reference(screen,,0) is no-op thanks to "if (ptr != refererence)" in

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #12 from Michel Dänzer --- It should be fine. You're right that fence_finish can run concurrently in multiple threads, but even if it returns true in multiple threads, the fence_reference calls are serialized by

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #11 from shinji.suz...@gmail.com --- Sorry I've made too many mistake in writing. (Should have gone to bed before writing.) I'll rewrite whole post below. I'm afraid execution of st_fence_sync() can still race. Thread-A can run upto

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #10 from shinji.suz...@gmail.com --- >I'm not confortable about sreen->fence_ference() being called concurrently. I'm not comfortable about sreen->fence_finish() being called concurrently. -- You are receiving this mail because:

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #9 from shinji.suz...@gmail.com --- oops. I'm getting confused. Concurrent programmingis hard. > screen->fence_reference(screen, >fence, NULL); will not be executed in arbitrary order but serially due to the mutex locking. Still the

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #8 from shinji.suz...@gmail.com --- Comment on attachment 127267 --> https://bugs.freedesktop.org/attachment.cgi?id=127267 Lock the shared state mutex and work with a local reference of so->fence Review of attachment 127267:

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 Michel Dänzer changed: What|Removed |Added Attachment #127204|0 |1 is

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 Michel Dänzer changed: What|Removed |Added Attachment #127237|0 |1 is

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #6 from shinji.suz...@gmail.com --- Created attachment 127237 --> https://bugs.freedesktop.org/attachment.cgi?id=127237=edit Diff that went into my copy of mesa-source -- You are receiving this mail because: You are the QA Contact

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #5 from shinji.suz...@gmail.com --- Hello Michael-san. I'm afraid my testing was not enough and I spoke too soon. Today I've run my app remotely through ssh session by pointing DISPLAY to :0 as I'm away from my home machine. Now the

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #4 from Michel Dänzer --- Shinji-san, (In reply to shinji.suzuki from comment #3) > Yes, it does! Thank you for your interest and effort in solving the issue. Great, thank you for testing the patch. > My itch

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #3 from shinji.suz...@gmail.com --- (In reply to Michel Dänzer from comment #2) > Created attachment 127204 [details] [review] > Work with a local reference of so->fence > > Does this patch help? Yes, it does! Thank you for your

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #2 from Michel Dänzer --- Created attachment 127204 --> https://bugs.freedesktop.org/attachment.cgi?id=127204=edit Work with a local reference of so->fence Does this patch help? -- You are receiving this mail

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

https://bugs.freedesktop.org/show_bug.cgi?id=98172 shinji.suz...@gmail.com changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.