Hide Forgot
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
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