-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add gdb backtrace to qa tests when server fails to start within timeout #5310
Conversation
This looks good. You can also try to capture gdb stack trace for an encountered segmentation fault. |
@tanmayv25 Reading through the util script logic, I think this actually covers the case where server exits early (segfault) as well. Looks like this part would return early and set WAIT_RET=1:
So my wording in I will double check this. |
@rmccorm4 You are right. I was mistaking WAIT_RET to be the actual time pending to start the server. You can improve the language in message. Also, some changes would be required as the SERVER_PID will not be active for segfaults. |
Update, on a segfault, the process has already exited before coming this far, so
Not sure the best way to handle this. It looks like you'd need a Also, even if this worked I think this only captures segfault on server startup and does not capture after the server has successfully started and the test/client request triggers a segfault. Some other ideas off the top of my head:
Either way, we can look into capturing segfaults separately from these changes, I'll update the language around "hang". |
@GuanLuo added core dump with
|
Help to better debug server hangs moving forward by capturing relevant backtrace rather than having to try to reproduce locally each time.
To demonstrate if it works or not, I added an intentional deadlock in
model_lifecycle.cc
on model load. Here's the output from the test. Note that even for a RELEASE build this helps point to an issue in core:For issues on shared libraries (backends etc.) or issues requiring more detailed information, I am looking to add a DEBUG build as well.
However, I think it's valuable to have it running in the RELEASE build tests as well just in case it appears in one build type and not the other in CI:
Test + GDB Backtrace Log