https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
--- Comment #17 from Eric Covener <[email protected]> --- (In reply to Ruediger Pluem from comment #16) > (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? both pairs of threads / both crash scenarios. > > 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? That is what I was thinking. but maybe this is not as simple/similar due to the way worker->cp is already lazily created? -- 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]
