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

Crash when cleaning up persistent sockets #3074

Closed
jmarrama opened this issue Jul 1, 2014 · 1 comment
Closed

Crash when cleaning up persistent sockets #3074

jmarrama opened this issue Jul 1, 2014 · 1 comment
Labels

Comments

@jmarrama
Copy link
Contributor

jmarrama commented Jul 1, 2014

I get the following stacktrace:

#0 ?? at hhvm/hphp/util/process.h:0
#1 __restore_rt at sigaction.c:0
#2 HPHP::sockopen_impl(HPHP::HostURL const&, HPHP::VRefParamValue const&, HPHP::VRefParamValue const&, double, bool) at hhvm/hphp/runtime/ext/ext_socket.cpp:1090
#3 HPHP::f_pfsockopen(HPHP::String const&, int, HPHP::VRefParamValue const&, HPHP::VRefParamValue const&, double) at /opt/rh/devtoolset-2/root/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/basic_string.h:0
#4 HPHP::JIT::X64::BackEnd::enterTCHelper(unsigned char*, HPHP::JIT::TReqInfo&) at hhvm/hphp/runtime/vm/jit/back-end-x64.cpp:113
#5 HPHP::JIT::MCGenerator::enterTC(unsigned char*, void*) at hhvm/hphp/runtime/base/rds-header.h:0
#6 HPHP::ExecutionContext::enterVMAtCurPC() at hhvm/hphp/runtime/vm/jit/mc-generator.h:225
#7 HPHP::ExecutionContext::enterVM(HPHP::ActRec*, HPHP::ExecutionContext::StackArgsState, HPHP::Resumable*, HPHP::ObjectData*) at hhvm/hphp/runtime/vm/bytecode.cpp:1947

#8 HPHP::ExecutionContext::invokeFunc(HPHP::TypedValue*, HPHP::Func const*, HPHP::Variant const&, HPHP::ObjectData*, HPHP::Class*, HPHP::VarEnv*, HPHP::StringData*, HPHP::ExecutionContext::InvokeFlags) at hhvm/hphp/runtime/vm/vm-regs.h:0
#9 HPHP::ObjectData::o_invoke(HPHP::String const&, HPHP::Variant const&, bool) at hhvm/hphp/runtime/base/type-variant.h:0
#10 HPHP::f_hphp_invoke_method(HPHP::Variant const&, HPHP::String const&, HPHP::String const&, HPHP::Variant const&) at hhvm/hphp/runtime/ext/reflection/ext_reflection.cpp:359
#11 HPHP::JIT::X64::BackEnd::enterTCHelper(unsigned char*, HPHP::JIT::TReqInfo&) at hhvm/hphp/runtime/vm/jit/back-end-x64.cpp:113
#12 HPHP::JIT::MCGenerator::enterTC(unsigned char*, void*) at hhvm/hphp/runtime/base/rds-header.h:0
#13 HPHP::ExecutionContext::enterVMAtCurPC() at hhvm/hphp/runtime/vm/jit/mc-generator.h:225
#14 HPHP::ExecutionContext::enterVM(HPHP::ActRec*, HPHP::ExecutionContext::StackArgsState, HPHP::Resumable*, HPHP::ObjectData*) at hhvm/hphp/runtime/vm/bytecode.cpp:1947
#15 HPHP::ExecutionContext::invokeFunc(HPHP::TypedValue*, HPHP::Func const*, HPHP::Variant const&, HPHP::ObjectData*, HPHP::Class*, HPHP::VarEnv*, HPHP::StringData*, HPHP::ExecutionContext::InvokeFlags) at hhvm/hphp/runtime/vm/vm-regs.h:0
#16 HPHP::ExecutionContext::invokeUnit(HPHP::TypedValue*, HPHP::Unit const*) at hhvm/hphp/runtime/vm/bytecode.cpp:2244
.....

The offending line at ext_socket.cpp:1090 was added in one of my recent pull requests to fix a failing test (see the last commit).

I'm worried that there might be a bad race condition between Sweepable::SweepAll() and calling sock->Close(), or something else weird is happening. FWIW, I observed this problem after clearing HHVM's on-disk HHBC cache.

@LiraNuna LiraNuna added the crash label Jul 1, 2014
@jmarrama
Copy link
Contributor Author

jmarrama commented Jul 2, 2014

Finally got a core dump - this issue is very occasionally reoccurring. It contained some relevant information:

(gdb) bt
#0  0x00000000017eca1d in HPHP::sockopen_impl (hosturl=..., errnum=..., errstr=..., timeout=timeout@entry=0.10000000000000001, persistent=persistent@entry=true) at hphp/runtime/ext/ext_socket.cpp:1090
#1  0x00000000017ed95b in HPHP::f_pfsockopen (hostname=..., port=7911, errnum=..., errstr=..., timeout=<optimized out>) at hphp/runtime/ext/ext_socket.cpp:1201
#2  0x00000000058f4e3a in ?? ()
#3  0x0000000000001ee7 in ?? ()
#4  0x00007fe6dd8fb7b0 in ?? ()
#5  0x3fb999999999999a in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) p sock->m_error
$33 = 32
(gdb) p sock->m_closed
$34 = 231
(gdb) p (bool) sock->m_closed
$35 = true
(gdb) p sock->m_fd
$36 = 917677344
(gdb) p sock->m_persistentCount
$37 = 1
(gdb) p sock->m_sweepNode
$38 = {next = 0x0, prev = 0x7fe735ef18e0}
(gdb) p sock->m_type
$39 = 0
(gdb) p sock->m_address
$40 = ""
(gdb) p sock->m_port
$41 = 62927168
(gdb) p key
$42 = "some.internal.server.box.net:7911"
(gdb) p sock
$43 = (HPHP::Socket *) 0x7fe71a779580

jmarrama added a commit to jmarrama/hhvm that referenced this issue Jul 15, 2014
This is a fix for facebook#3074 where cleaning up dead persistent sockets
sometimes caused a segfault, because the dead socket was removed
from the persistent resource store before being closed. Removing
an object from the persistent resource store can end up deleting
the object, which is what happened in the segfault case.
facebook-github-bot pushed a commit that referenced this issue Jul 16, 2014
Summary: This is a fix for #3074 where cleaning up dead persistent sockets
sometimes caused a segfault, because the dead socket was removed
from the persistent resource store before being closed. Removing
an object from the persistent resource store can end up deleting
the object, which is what happened in the segfault case.
Closes #3101
Created from: #3101

Reviewed By: mwilliams, ptarjan

Differential Revision: D1435379
@ptarjan ptarjan closed this as completed Jul 25, 2014
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

3 participants