[SERVER-2147] is printStackTrace() signal safe? Created: 25/Nov/10 Updated: 07/Jan/20 Resolved: 07/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Stability |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Trivial - P5 |
| Reporter: | Dwight Merriman | Assignee: | Billy Donahue |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Dev Tools 2020-01-13 | ||||||||
| Participants: | |||||||||
| Description |
|
my understanding is that malloc shouldn't be used in signals. is that correct? (1) ostream is used in printStackTrace(). does ostream call malloc? I imagine so. so what to do, as a stack trace might be helpful. one option is just make sure anything "important" is done first, and that stdout is flushed, and then just try it. (1) and (3) could be eliminated but perhaps #2 is hard. |
| Comments |
| Comment by Billy Donahue [ 02/Jan/20 ] |
|
Spencer, I think it's basically a dupe of Let's merge the tickets. |
| Comment by Alberto Lerner [ 25/Nov/10 ] |
|
For completeness, this is the step that should help in extreme memory pressure. I think some libs we use throw SIGABRTs in lack of memory (and we assert, which is the same). So having stack space set aside to handle those should help. http://www.gnu.org/software/libc/manual/html_mono/libc.html#Signal-Stack |
| Comment by Alberto Lerner [ 25/Nov/10 ] |
|
Please, have a look at util/signal_handlers. {h,cpp}. I think they address these issues. malloc and iostreams are not signal safe There is still the issue of extreme OOM, where even stack allocation is not doable. We can reserve a space statically and use it on the signal handler. But I haven't gotten a chance to simulate and test this. |