https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
--- Comment #16 from Ruediger Pluem <[email protected]> --- (In reply to Eric Covener from comment #15) > (In reply to Ruediger Pluem from comment #14) > > (In reply to Don Poitras from comment #13) > > > Testing a new fix requires multiple people to be involved and some hours > > > of > > > work to get the test done. Seeing that the proposed fix won't address the > > > "second example", it's not something we'd be able to test. If you'd like > > > us > > > to test something meant to fix all the failures, we'd probably be able to > > > do > > > that. > > > > Ok. Will try to do this. > > @Eric any comments from you reviewing my approach? Do you think it gets into > > the correct direction from your point of view? > > I did also think a 2nd thread was concurrently in > ap_proxy_initialize_worker() which would leave both using the original > worker->cp->pool due to the inconsistent way it's guarded. > > I guess the fourth backtrace has some missing frames (from the numbering) > and is also in apr_sockaddr_info_get()? I am not sure. But if it's right > then both are DNS. I agree that lines are missing in the forth backtrace. What do you mean by both? 2nd and 4th backtrace? > > If we can use a sub-pool, we can add it as volatile and key off of it > solving the (potential?) ABI problem with the double-check after grabbing > the global mutex. So with a sub-pool of worker->cp->pool dedicated for the apr_sockaddr_info_get call you propose to mark worker->cp->addr as volatile and recheck it after getting the lock just as I did in my patch with worker->local_status? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
