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

Implement a well-behaved stack trace printer (75x backport) #10422

Merged

Conversation

bbockelm
Copy link
Contributor

Backport of #10084 to 75x.

This implements a stack trace printer which is safe to call
from a signal handler (ROOT's stack trace printer is not async-signal
safe; see 'man 7 signal' for more information about async-signal
safety).

Further, on Linux, this utilizes the clone library call directly;
clone has the advantage of avoiding the pthread_atfork handlers.
We have observed that jemalloc currently registers AS-unsafe atfork
handlers, which would cause a deadlock if we use fork().

(cherry picked from commit cff10d3)
This switches from the system pstack script to using gdb directly.
Ideally, this will be more usable on non-Linux platforms.

NOTE that this will pull the gdb from the environment (i.e., probably
CMSSW's gdb instead of the system one).  CMSSW's gdb can parse the
debug symbols we ship, meaning that the backtrace will include
niceties like filenames, line numbers, and decode arguments.

The downside of this is that CMSSW's gdb requires 10 minutes
and about 1GB RAM to generate the traceback.

(cherry picked from commit b6d0bae)
@cmsbuild
Copy link
Contributor

A new Pull Request was created by @bbockelm (Brian Bockelman) for CMSSW_7_5_X.

Implement a well-behaved stack trace printer (75x backport)

It involves the following packages:

FWCore/Services

@cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks.
@Martin-Grunewald, @wddgit, @wmtan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

@Dr15Jones
Copy link
Contributor

please test

@Dr15Jones
Copy link
Contributor

+1

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs once checked with relvals in the development release cycle of CMSSW or unless it breaks tests. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10422/6775/summary.html

The workflows 140.53 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs once checked with relvals in the development release cycle of CMSSW (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

@davidlange6
Copy link
Contributor

+1

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.

None yet

4 participants