Debugging grpc C++ Addons with gdb: Practical Tips and Commands

The author recently encountered a grpc C++ addon issue where running the test suite of grpc-node/packages/grpc-native-core on a server often caused a segmentation fault. Modifying the C++ source to add logging is slow because it requires recompilation each time. Using gdb provides a more convenient way to debug; the following tips are shared.

Preparation

Ensure that gdb is installed on the server where debugging will take place.

Launch

Start Node.js under gdb:

gdb --args ~/.nvm/versions/node/v12.4.0/bin/node

Run

Within the gdb prompt, run the program you need to debug, for example: (gdb)run ./node_modules/.bin/_mocha test If a segmentation fault occurs, use the bt command to print the backtrace. Example output:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4639d82 in uv_socket_bind (socket=0x2236fe0, addr=0x7fffffffb890, len=<optimized out>, flags=0) at ../deps/grpc/src/core/lib/iomgr/tcp_uv.cc:302
#0  0x00007ffff4639d82 in uv_socket_bind (socket=0x2236fe0, addr=0x7fffffffb890, len=<optimized out>, flags=0) at ../deps/grpc/src/core/lib/iomgr/tcp_uv.cc:302
#1  0x00007ffff469528b in add_socket_to_server (listener=<synthetic pointer>, port_index=0, addr=0x7fffffffb890, socket=0x2236fe0, s=0x2238640) at ../deps/grpc/src/core/lib/iomgr/tcp_server_custom.cc:282
#2  tcp_server_add_port (s=<optimized out>, addr=0x7fffffffb890, port=<optimized out>) at ../deps/grpc/src/core/lib/iomgr/tcp_server_custom.cc:396
#3  0x00007ffff468444b in grpc_chttp2_server_add_port (server=server@entry=0x22bc950, addr=addr@entry=0x7fffffffbca0 "127.0.0.1:12265", args=0x2286580, port_num=port_num@entry=0x7fffffffbbdc) at ../deps/grpc/src/core/ext/transport/chttp2/server/chttp2_server.cc:334
#4  0x00007ffff468513d in grpc_server_add_insecure_http2_port (server=0x22bc950, addr=0x7fffffffbca0 "127.0.0.1:12265") at ../deps/grpc/src/core/ext/transport/chttp2/server/insecure/server_chttp2.cc:37
#5  0x00007ffff462bb35 in grpc::node::Server::AddHttp2Port (info=...) at ../ext/server.cc:266
#6  0x00007ffff462b2d6 in Nan::imp::FunctionCallbackWrapper (info=...) at ../node_modules/nan/nan_callbacks_12_inl.h:176
#7  0x0000000000a98153 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#8  0x0000000000b0f37c in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
#9  0x0000000000b0ffcf in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()

Set Breakpoints

Often the backtrace alone does not provide enough information; setting breakpoints is necessary.

Set a breakpoint on a function: (gdb) b uv_tcp_bind Or set a breakpoint on a specific line in a source file: (gdb) b tcp_uv.cc:302 Run the program again; execution stops at the breakpoint, showing the relevant source line:

Breakpoint 1, uv_socket_bind (socket=0x2238510, addr=0x7fffffff b890, len=28, flags=0) at ../deps/grpc/src/core/lib/iomgr/tcp_uv.cc:302
302        uv_tcp_bind((uv_tcp_t*)uv_socket->handle, (struct sockaddr*)addr, 0);

Useful gdb Commands at a Breakpoint

Use print to display variable values.

Use bt to view the call stack.

Enter c to continue execution to the next breakpoint.

Enter n to execute the next statement.

Enter s to step into a function.

The exact usage depends on the specific scenario; readers are encouraged to share their experiences and questions.