Closed
Bug 720704
Opened 13 years ago
Closed 13 years ago
Avoid setting an alternative stack for signals if there is already one
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: glandium, Assigned: glandium)
References
()
Details
Attachments
(1 file)
2.98 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
The software in which breakpad is hooked may well have already set an alternative stack for signals for separate reasons. Breakpad should use that alternative stack if it's large enough.
http://code.google.com/p/google-breakpad/issues/detail?id=464
Assignee | ||
Comment 1•13 years ago
|
||
Attachment #591101 -
Flags: review?(ted.mielczarek)
Comment 2•13 years ago
|
||
Comment on attachment 591101 [details] [diff] [review]
Avoid setting an alternative stack for signals if there is already one
Review of attachment 591101 [details] [diff] [review]:
-----------------------------------------------------------------
This looks fine. Needs to land upstream as well.
::: toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc
@@ -189,5 @@
> // We use this value rather than SIGSTKSZ because we would end up overrunning
> // such a small stack.
> static const unsigned kSigStackSize = 8192;
>
> - signal_stack = malloc(kSigStackSize);
Does calling sigaltstack hand over ownership of the stack memory?
Attachment #591101 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 3•13 years ago
|
||
(In reply to Ted Mielczarek [:ted, :luser] from comment #2)
> Does calling sigaltstack hand over ownership of the stack memory?
No, so effectively, this is leaked memory. But that is a feature of the existing code already.
Assignee | ||
Comment 4•13 years ago
|
||
Comment 5•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in
before you can comment on or make changes to this bug.
Description
•