The current situation is, from what I can tell, worse and more pervasive than the original bug.
> On Apr 18, 2018, at 10:01 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > This isn't fair Jim, the previous code didn't work as expected either, IMHO. > > Regarding PR 62277 for instance, it worked because it attach()ed SHMs > of unrelated balancers instead of creating new ones (this was the > paper over SysV vs Posix, not the actual code which I think shows the > real/potential issue on some systems). > > For this PR 62308, let's see if this is a crash or the annoying AH02599 > "only". > In both cases "mea culpa maxima" (flogging myself and so on) but yes > changes can be buggy and I don't see why you seem to imply that all > this was gratuitous and for the sake of changing/breaking code. It was > intended to be bug fixes only, any bug revealed by the previous being > fixed itself fixed, when should we give up? I don't... > > Please let's be constructive and not impugn motives on why a code is > changed, it's sometimes simply needed, and in any case open to > review/feedback/veto/tests at any time, including when it's proposed > for backport. > > > On Wed, Apr 18, 2018 at 1:56 PM, Jim Jagielski <j...@jagunet.com> wrote: >> Most likely it is due to some assumptions in slotmem based on the underlying >> shm implementation, ie: SysV or Posix. >> >> I would be remiss is pointing out that here is yet another case where >> instead of a simple fix for a bug, we instead refactored a sh*t-ton of code >> and in the process, broke stuff. >> >> Can we PLEASE avoid using bug reports as opportunities to >> show everyone how smart we are and rewrite whole swaths of >> code... please! >> >> >> On Apr 17, 2018, at 12:37 PM, Exonetric <m...@exonetric.com> wrote: >> >> FWIW, I am seeing this too, but examining the code I could not see how. It >> looks like it just does a shm destroy and then moves on to recreating the >> SHM segment. >> >> On 17 Apr 2018, at 14:03, Jim Jagielski <j...@jagunet.com> wrote: >> >> This should not be a fatal error... I don't think it was before. >> >> Begin forwarded message: >> >> From: bugzi...@apache.org >> Subject: [Bug 62308] New: Apache crashes after graceful restart with >> AH02599: slotmem (failed size check) >> Date: April 17, 2018 at 6:21:09 AM EDT >> To: b...@httpd.apache.org >> Reply-To: "Apache HTTPD Bugs Notification List" <b...@httpd.apache.org> >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=62308 >> >> Bug ID: 62308 >> Summary: Apache crashes after graceful restart with AH02599: >> slotmem (failed size check) >> Product: Apache httpd-2 >> Version: 2.4.33 >> Hardware: PC >> Status: NEW >> Severity: regression >> Priority: P2 >> Component: mod_proxy_balancer >> Assignee: b...@httpd.apache.org >> Reporter: d...@d-velop.de >> Target Milestone: --- >> >> Created attachment 35878 >> --> https://bz.apache.org/bugzilla/attachment.cgi?id=35878&action=edit >> logfile with configuration change example >> >> After updating from 2.4.27 to 2.4.33, we get a crash when doing a graceful >> restart after modifying the mod_proxy/mod_proxy_balancer configuration in >> the >> filesystem. >> We are modifying the configuration files dynamicaly when our infrastructure >> changes. After this, we do a graceful restart using the following Windows >> command: httpd.exe -k restart >> This worked fine with 2.4.27 and below. >> With 2.4.33 we get the following message: >> AH02599: existing shared memory for >> C:/Apache24/temp/slotmem-shm-p17ffdef3.shm >> could not be used (failed size check) >> >> I've added a Apache logfile with an example of configuration change that >> causes >> this issue >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org >> For additional commands, e-mail: bugs-h...@httpd.apache.org >> >> >>
