Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hhvm crashes under heavy load #1934

Closed
marksamman opened this issue Feb 27, 2014 · 2 comments
Closed

hhvm crashes under heavy load #1934

marksamman opened this issue Feb 27, 2014 · 2 comments
Labels

Comments

@marksamman
Copy link

The latest hhvm-nightly from the Debian 7 64-bit apt repository is crashing under heavy load.

Running hhvm with this command:
hhvm -m server -c config.hdf

config.hdf only contains:

Server {
        Port = 8080
}

The PHP script I'm running is as simple as:

<?php
echo 'Hello World';

The command I use to reproduce this:
ab -n 5000 -c 4 http://localhost:8080/helloworld.php

gdb bt on the core dump shows:

(gdb) bt
#0  __strcasecmp_l_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:213
#1  0x00007fad2347cb3c in evhttp_find_header (
    headers=headers@entry=0x7fad0fe97a90, 
    key=key@entry=0x7fad23486f86 "Transfer-Encoding") at http.c:1373
#2  0x00007fad2347d00a in evhttp_maybe_add_content_length_header (
    content_length=11, headers=0x7fad0fe97a90) at http.c:455
#3  evhttp_make_header_response (req=0x7fad135b29c0, evcon=<optimized out>)
    at http.c:493
#4  evhttp_make_header (evcon=evcon@entry=0x7fad138a4f80, 
    req=req@entry=0x7fad135b29c0) at http.c:528
#5  0x00007fad2347de03 in evhttp_send_reply_sync_begin (req=0x7fad135b29c0, 
    code=<optimized out>, reason=<optimized out>, databuf=0x0) at http.c:2022
#6  0x0000000000f4ebf2 in HPHP::LibEventServer::onResponse(int, evhttp_request*, int, HPHP::LibEventTransport*) ()
#7  0x0000000000f39701 in HPHP::LibEventTransport::sendImpl(void const*, int, int, bool) ()
#8  0x0000000000f71c02 in HPHP::Transport::sendRawLocked(void*, int, int, bool, bool, char const*) ()
#9  0x0000000000f3b1a2 in HPHP::HttpRequestHandler::executePHPRequest(HPHP::Transport*, HPHP::RequestURI&, HPHP::SourceRootInfo&, bool) ()
#10 0x0000000000f3c3a0 in HPHP::HttpRequestHandler::handleRequest(HPHP::Transport*) ()
#11 0x0000000000f223a8 in HPHP::ServerWorker<std::shared_ptr<HPHP::LibEventJob>, HPHP::LibEventTransportTraits>::doJobImpl(std::shared_ptr<HPHP::LibEventJob>, bool) ()
#12 0x0000000000f22648 in HPHP::ServerWorker<std::shared_ptr<HPHP::LibEventJob>, HPHP::LibEventTransportTraits>::doJob(std::shared_ptr<HPHP::LibEventJob>) ()
#13 0x0000000000f21ae7 in HPHP::JobQueueWorker<std::shared_ptr<HPHP::LibEventJob>, HPHP::Server*, true, false, HPHP::JobQueueDropVMStack>::start() ()
#14 0x00000000015db3a7 in HPHP::AsyncFuncImpl::threadFuncImpl() ()
#15 0x00000000015db54b in HPHP::AsyncFuncImpl::ThreadFunc(void*) ()
#16 0x00007fad220b7b50 in start_thread (arg=<optimized out>)
    at pthread_create.c:304
#17 0x00007fad216630ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#18 0x0000000000000000 in ?? ()

Sometimes it stops responding to requests (0% cpu usage) instead of crashing, so I'm guessing there could be a deadlock somewhere too.

@scannell scannell added the crash label Feb 27, 2014
@scannell
Copy link
Contributor

Thanks for reporting this. Feel free to submit a PR if you (or someone else reading this) figures this out before we do.

@marksamman
Copy link
Author

I've updated to the latest nightly and this appears to have been fixed, #1937 might have been a duplicate report of this too (I had similar backtraces). Closing this issue as I'm no longer able to reproduce it.

facebook-github-bot pushed a commit that referenced this issue Feb 22, 2024
Summary:
D43401609, derived from [PR #1934](facebook/folly#1934), allows the move constructor to use `memcpy` to relocate the inline storage for relocatable types, but it copies the whole storage disregarding the previous limitation on size for trivial types (which are a subset of relocatable types). Furthermore, the same optimization is not applied to the move-assignment operator.

This diff restores the size limitation (using a precise copy when relocating inline buffers that exceed it) and applies the same logic to move-assignment.

Also, since now we can assume C++17 and thus `if constexpr`, I removed the unnecessary overload of `copyInlineTrivial()`, and I made the names less ambiguous.

We might also benefit from special-casing relocatable types on reallocation in `makeSizeInternal()`, but that can be done separately.

Reviewed By: Gownta

Differential Revision: D53965673

fbshipit-source-id: 2939c03ada3b19d4fadfa11621a3e2f3afc5ccb7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants