| Summary: | coroipcc_service_connect forces threads stacks > 12*4k | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Corosync Cluster Engine | Reporter: | dan clark <2clarkd> | ||||||
| Component: | unknown | Assignee: | Jan Friesse <jfriesse> | ||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 1.4 | CC: | agk, asalkeld, fdinitto, jfriesse, sdake | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-08-17 07:47:09 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
Honza, Patch looks ok to me for master. Could you make a proper git commit and submit to ml so it can be reviewed (give Dan Clark credit for the work please). Thanks! -steve Created attachment 515547 [details]
Patch sent to ML
Patch sent to ML. It's GITized version of original patch + extra memset to avoid valgrind warnings.
Patch is now included in flatiron branch, and will be included in next release. |
Created attachment 514263 [details] proposed diff agains corosync-1.4.0 that provides dynamic allocation/free 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): corosync-1.4.0 How reproducible: always Steps to Reproduce: 1. create an application thread with a small stack to restart (cpg_model_initialize or cpg_initialize) when a failure is detected. 2. 3. Actual results: threads with small stack sizes corrupt memory Expected results: use of small stacks sizes is acceptable when using corosync library. Additional info: