Issue 119008 - Unititialized member bOneWay in typelib_typedescription_newEmpty
Summary: Unititialized member bOneWay in typelib_typedescription_newEmpty
Status: CONFIRMED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC All
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needhelp
Depends on:
Blocks:
 
Reported: 2012-03-02 14:16 UTC by olistraub
Modified: 2018-11-11 15:21 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
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.