From the context of the bug report, this work was towards an SRU for trusty,
for fixes included in newer releases.
Trusty is no longer under standard support. Unless this is reproducible in
bionic or newer, I think we can consider this as fixed for supported releases.
** Changed in: apache2
Ah, that makes sense.
On Mon, Dec 10, 2018 at 6:50 AM Andreas Hasenack
wrote:
> > However, I would prefer that someone with more Apache experience
> reviewed the fix.
>
> Right, that was actually my (very unclear, sorry) point when I commented
> on upstream's interest in this, since they would
> However, I would prefer that someone with more Apache experience
reviewed the fix.
Right, that was actually my (very unclear, sorry) point when I commented
on upstream's interest in this, since they would be experienced
reviewers.
--
You received this bug notification because you are a member
> However, I would prefer that someone with more Apache experience
reviewed the fix.
Right, that was actually my (very unclear, sorry) point when I commented
on upstream's interest in this, since they would be experienced
reviewers.
--
You received this bug notification because you are a member
Andreas,
I think patching this in Ubuntu only rather than upstream makes sense for
the reasons you've outlined. However, I would prefer that someone with more
Apache experience reviewed the fix.
Thanks,
Brian
On Fri, Dec 7, 2018 at 10:21 AM Christophe Meron <1630...@bugs.launchpad.net>
wrote:
Unfortunately, not really
I can argue on why we use Trusty: as we deploy storage software which
runs for years in controlled environment, we never upgrade OSes to new
releases. Our older platforms are still on Trusty and that makes sense
to me.
But that doesn't make an argument to why they
I'm not sure how likely this bug is to get attention from upstream for
an old version of apache, unless the problem still happens with the
latest release. Any ideas?
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
I'm not sure how likely this bug is to get attention from upstream for
an old version of apache, unless the problem still happens with the
latest release. Any ideas?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thanks for the clarification Christophe. So it sounds like the fix
addresses the problem. I think the patch in that PPA should get more
review from an Apache developer before it is used further.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi Brian,
The crash doesn't occur with your PPA packages (2.4.7-1ubuntu4.19)
To be more precise: it systematically crash on 1 run of the reproducer without
your PPA, and i dont have crash with 10 runs of the reproducer on your PPA. I
didnt test further but it sound reasonable to me so far.
Hi Christophe,
Sorry for the delay. Apparently I wasn't getting these notifications for
some reason. I'm not well versed enough with Docker to set up an
environment to reproduce. I use LXD almost exclusively. Does the crash
occur in your Docker container with my patched PPA build? Andreas seems
Just a ping on this bug, confirming it's still in our queue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
segfault in server/mpm/event/event.c:process_socket
To manage
Just a ping on this bug, confirming it's still in our queue.
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1630413
Title:
segfault in server/mpm/event/event.c:process_socket
To manage
Hi Andreas, thanks for your update !
For your initial question: we initially reproduced on docker containers,
yes. I just tried on a VM with the same procedure and i could reproduce
the issue so it doesnt seems related to container environment
--
You received this bug notification because you
** Changed in: apache2 (Ubuntu)
Importance: Undecided => Medium
** Changed in: apache2 (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
** Changed in: apache2 (Ubuntu)
Importance: Undecided => Medium
** Changed in: apache2 (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
Some more testing. With the packages from Brian's ppa, the crash doesn't
happen. I can't vouch for the patch itself since I'm not familiar at all
with that code, though.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in
Some more testing. With the packages from Brian's ppa, the crash doesn't
happen. I can't vouch for the patch itself since I'm not familiar at all
with that code, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Sorry, I had a setup problem. I can reproduce the problem in an LXD
container as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
segfault in
Sorry, I had a setup problem. I can reproduce the problem in an LXD
container as well.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
segfault in
Interesting, I don't get the segfault with the script in a lxd
container.
@chris+launchpad-ielf, is your original segfault scenario inside a
docker container as well? I wonder if some resource constraints could be
at play here.
--
You received this bug notification because you are a member of
Interesting, I don't get the segfault with the script in a lxd
container.
@chris+launchpad-ielf, is your original segfault scenario inside a
docker container as well? I wonder if some resource constraints could be
at play here.
--
You received this bug notification because you are a member of
The trusty docker file does reproduce the segfault, fwiw. I'll just
still try to reproduce it in a lxd container, now that I have the setup
instructions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The trusty docker file does reproduce the segfault, fwiw. I'll just
still try to reproduce it in a lxd container, now that I have the setup
instructions.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
Hi Brian,
Here is the requested config output if it helps
Were you able to reproduce with the docker containers ?
Christophe
# apache2ctl -M
AH00558: apache2: Could not reliably determine the server's fully qualified
domain name, using 172.17.0.6. Set the 'ServerName' directive globally to
Here is the Xenial version which does *not* reproduce the issue,
hopefully :)
(docker build -t apache-1630413 . && docker run apache-1630413 bash
/root/run.sh)
** Attachment added: "apache2-1630413-docker-xenial.tgz"
Hi Brian,
Check the attached archive, i did a small dockerfile so you see what i
exactly install in it, and hopefully could reproduce it
cd
docker build -t apache-1630413 .
docker run -it apache-1630413
# in container:
service php5-fpm start && service apache2 start
curl localhost/50M.php |
Hi Christophe,
Thanks for your hard work on this one. Unfortunately I can't reproduce
the crash with your test. I even raised the file size to 500M, but still
nothing.
Is there anything I could be missing? Any PPA packages with newer
versions of PHP or other Apache modules loaded?
Previous archive was missing content, here is the right one
Dont forget to generate the 50M file in /tmp as i doesnt seems to
trigger the bug if the content if not big enough
** Attachment added: "php-test.tgz"
Hi Brian,
Some news:
I tried to reproduce the crash with php5-fpm as a backend of fastcgi. I
ran the same test on a php file doing a readfile() on a 50MB file again
and i can reproduce the crash systematically !
Here is the script and config file attached
Nothing particular, used php5-fpm
I would have wanted to provide the full chain of the reproducer, but
days has already passed, here is the information i can provide for now:
I reproduce the crash with a simple:
rm failed; for i in $(seq 200); do (curl -qo /dev/null "$URL" || touch failed)
& done
A single run usually is
Hi Christophe,
That is excellent. Could you please provide me with a test case that
previously reproduced the crash? I'd like to try to boil it down to
something simple. I will need to demonstrate that it can be reproduced
easily and consistently to get an SRU approved. There aren't a lot of
Hi Brian,
I finally did some functional testing
With 2 differents clients (!= IPs), i started on each of them 100
parrallel GETs, targeting 3 different files. I ran this in a loop with
some randomness for an hour and it didnt raised any crash nor
consistency mismatch on thoses fetched files
I
Fantastic news! My biggest concern now is that my monkey-patch has
introduced some unexpected behavior since we don't try to dereference
sbh on each read request (only when the connection state is suspended).
This is based on my own observation of the problem rather than an
upstream patch since
Good news, it seems good this time !
I almost always reproduced the segfault with a single run of my script
(which spawn 200 parrallel requests on a file on our daemon behind
fastcgi). Once i had to run it twice to reproduce.
With your last version, i didnt had any crash for 100 consecutives
Hi Christophe,
Let's try something completely different. I have a new build uploaded
for testing.
Thanks,
Brian
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
segfault in
Sure! Tried with your PPA, still got a segv
Program received signal SIGSEGV, Segmentation fault.
process_socket (my_thread_num=2, my_child_num=,
cs=0x7fd636a032a8, sock=, p=, thd=) at event.c:1066
gdb) bt full
#0 process_socket (my_thread_num=2, my_child_num=,
cs=0x7fd636a032a8, sock=, p=,
Hi Christophe,
I believe I've narrowed down the problem to one fixed in these two changesets:
https://github.com/apache/httpd/commit/59eea59c4be383d004e92fa63b57b995e7a8ef01
https://github.com/apache/httpd/commit/285e67883e396f97dc3aad50d9dc345f15220827
The latter only applies to 2.4.10 since it
Hi Brian,
Thanks for your fast answer and apologies for my delay
Unfortunately, i reproduced a similar crash on trusty-backports version
Not exactly the same though:
ii apache2
2.4.10-1ubuntu1.1~ubuntu14.04.2 amd64
Thanks for the core dump and bt Christophe. After a bit of research, I
believe this is a race condition present in 2.4.7 which was subsequently
patched, and then the patch refactored when the suspend/resume hooks
were added in 2.4.10. The fix in 2.4.7 seems simply enough (just move
c->sbh = NULL
Core from previous comment.
** Attachment added: "core.26498.bz2"
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1630413/+attachment/4933814/+files/core.26498.bz2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
We also encountered this issue with 2.4.7-1ubuntu4.17
I can reproduce it from times to times with a light parralel load (50-200
requests in //)
Here is some details:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f811d7fa700 (LWP 26536)]
process_socket
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apache2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1630413
Title:
Hi Ian, can you raise ulimit, add CoreDumpDirectory, and install
apache2-dbg (will restart to make prior two changes effective)? If you
make CoreDumpDirectory /tmp, make sure to move your core dump out of the
way before you reboot.
https://httpd.apache.org/dev/debugging.html#crashes
Then you'll
44 matches
Mail list logo
