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

Print necessary stackstace information when crashed #700

Merged
merged 2 commits into from
May 21, 2019

Conversation

withsmilo
Copy link
Collaborator

No description provided.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Clipper-PRB/1975/
Test FAILed.

@withsmilo
Copy link
Collaborator Author

https://amplab.cs.berkeley.edu/jenkins//job/Clipper-PRB/1975/ shows this error,

 [pytorch-container] The command '/bin/sh -c pip install -q torch==1.0.* torchvision==0.2.*' returned a non-zero code: 2 
CI_build.Makefile:472: recipe for target 'pytorch-container' failed
make: *** [pytorch-container] Error 2

@withsmilo
Copy link
Collaborator Author

Jenkins test this please

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Clipper-PRB/1977/
Test FAILed.

Copy link
Collaborator

@rkooo567 rkooo567 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general! I still have a couple questions.

  1. How is it different from just using docker logs on a broken container? Is it for our CI environment? 2. I found this notes from backtrace_symbols_fd

backtrace() and backtrace_symbols_fd() don't call malloc()
explicitly, but they are part of libgcc, which gets loaded
dynamically when first used. Dynamic loading usually triggers a
call to malloc(3). If you need certain calls to these two
functions to not allocate memory (in signal handlers, for
example), you need to make sure libgcc is loaded beforehand.

Are we loading libgcc beforehand? Is it already included in our compilation process?
EDIT -> Actually 2 might not matter because we print logs when containers are broken? Is docker container freeing all of its memory when it is broken?

@withsmilo
Copy link
Collaborator Author

@rkooo567
This PR will capture SIGSEGV(segmentation fault) only.

  1. After applying this, we could view stacktrace logs by using docker logs on a broken container.
  2. You're right. The resources of the broken container will be freed automatically.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Clipper-PRB/2001/
Test FAILed.

@withsmilo
Copy link
Collaborator Author

Jenkins test this please

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Clipper-PRB/2004/
Test PASSed.

Copy link
Collaborator

@rkooo567 rkooo567 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks nice!

@withsmilo withsmilo merged commit 9e41fb2 into ucbrise:develop May 21, 2019
@withsmilo withsmilo deleted the print_coredump branch May 21, 2019 05:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants