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 (Ub
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 b
> 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 should
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.
https://bugs.launchpa
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.
Con
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
to
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 notifications
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 ar
** 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:
s
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.
https://bugs.laun
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 server/mpm/event/event.c:process_socke
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 Ub
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.
https://bugs.launchpad.net/bugs/1
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
sup
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"
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1630413/+attachment/4
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 | cmp
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?
root@trusty-mp
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"
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1630413/+attachment/4945429
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 packag
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 enough,
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
repor
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 di
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 all
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 runs
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 server/mpm
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=, thd
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 in
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.
https://bug
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 (my_thread_n
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:
se
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 g
36 matches
Mail list logo