Issue 119008

Summary: Unititialized member bOneWay in typelib_typedescription_newEmpty
Product: udk Reporter: olistraub <openoffice>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Major    
Priority: P3 CC: knmc, pats, petko
Version: 3.4.0 Beta (OOo)Keywords: needhelp
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description olistraub 2012-03-02 14:16:28 UTC
In typelib_typedescription_newEmpty(), in the case typelib_TypeClass_INTERFACE_METHOD, the member variable bOneWay is not initialized. This might cause sporadic stack corruptions during synchronous IPC calls, since the urp_sendRequest_internal() call will not wait until the result has been stored but delete the object beforehand.
Comment 1 Keith N. McKenna 2016-10-14 01:18:38 UTC
This needs review by someone knowledgeable with the code to verify whether this is a viable issue or can be closed.
Comment 2 Patricia Shanahan 2016-10-14 02:23:16 UTC
The basic coding error, use of the uninitialized local variable, bOneWay, is present in both the trunk and 4.1.3. Assuming its value matters, the code is very fragile. A change in stack layout could make the difference between working and  not working.

Fixing it is probably relatively simple. We just need to find out the correct setting, and initialize bOneWay accordingly. It may be harder to test a fix - we need a test case that depends on the bad code.
Comment 3 Keith N. McKenna 2016-10-14 03:04:04 UTC
Based on Patricia's analysis I am marking this confirmed.
Comment 4 Keith N. McKenna 2018-11-09 16:28:46 UTC
Given the age and the difficulty of testing any fix should we consider setting this as Son't Fix?
Comment 5 Peter 2018-11-11 15:21:00 UTC
I think we should fix the Issue, even if we are not able to test the abuse. It would strengthen the code in general. We are fine if we check for regressions.