https://bz.apache.org/bugzilla/show_bug.cgi?id=57771
--- Comment #4 from Michael Thorpe <[email protected]> --- (In reply to Eric Covener from comment #3) > Anyone have an idea about what causes the ID to change? I don't think the > pool cleanups should run on a different thread then where the cgid handler > ran. Connection IDs can change any time the thread is put to sleep, which can happen basically any time Apache is waiting for something (like the output of an #exec). This bug was discovered on an SSI page that had an #exec followed by some #flastmod's. The #exec'ed script doesn't get cleaned up until the end of the page, and either due to load or scheduling issues the page would get handed off to another thread between the #flastmod's and the cleanup (although it could just as easily be handed off during the page generation itself). Nick Warne has a trace showing the problem if you need to see the timing, but the exact timing of the request isn't the problem. The problem is that mod_cgid is using the *current* connection ID (which isn't tied to the existing CGI if the connection gets handed off) instead of using the saved connection ID that was used to create the CGI process. This is why info->conn_id exists in the first place. You can see mod_cgid.c use it just 16 lines down from where it incorrectly uses info->r->connection->conn_id (line 1386 in 2.4.18). So when the thread has been handed off, mod_cgid will try to clean up the wrong ID then spit out an error message that refers to a different ID. The patch is very simple and obviously correct, and should be applied to trunk. Is there a reason it hasn't been? -- 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]
