| Summary: | [RFE] corosync coroipcc: use malloc for path in service_connect | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jan Friesse <jfriesse> | ||||
| Component: | corosync | Assignee: | Jan Friesse <jfriesse> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 6.2 | CC: | cluster-maint, jkortus, sdake | ||||
| Target Milestone: | rc | Keywords: | FutureFeature | ||||
| Target Release: | 6.3 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | corosync-1.4.1-5.el6 | Doc Type: | Enhancement | ||||
| Doc Text: |
Cause
Each IPC connection is using 48K in stack.
Consequence
Multi threading applications with reduced stack size don't work correctly
Fix
Allocate private IPC data on heap
Result
Each IPC connection is using 48K in heap, so multi threading applications no longer need to justify it's stack size.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-06-20 12:22:40 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 756082 | ||||||
| Attachments: |
|
||||||
In unit test, correct results are: Before patch: stacks(B) column is higher then 30K After patch: stacks(B) column is never higher then 20K
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
Each IPC connection is using 48K in stack.
Consequence
Multi threading applications with reduced stack size don't work correctly
Fix
Allocate private IPC data on heap
Result
Each IPC connection is using 48K in heap, so multi threading applications no longer need to justify it's stack size.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0777.html |
Created attachment 526634 [details] Proposed patch Description of problem: Coroipcc appropriately uses PATH_MAX sized variables for various data structures handling files in the initialization of the client. Due to the use of 12 of these structures declared as stack variables, the application stack balloons to over 12*4k. This is especially problematic if threads are used by long running daemons to restart the connection to corosync so as to be resilient in the face of system services restarting (service corosync restart). A simple alternative is to allocate temporary memory to avoid requirements of large thread stacks. Version-Release number of selected component (if applicable): 1.4.1 Additional info: Patch exists in corosync 1.4.2 Unit test: use massif tool, and testcpg where first operation is ctrl+d. valgrind --tool=massif --stacks=yes ./testcpg ms_print massif.out.* Before patch: stacks(B) column is never higher then 20K After patch: stacks(B) column is higher then 30K