RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c

David Holmes david.holmes at oracle.com
Tue Mar 5 16:48:56 PST 2013


On 6/03/2013 10:44 AM, Dean Long wrote:
> On 3/5/2013 3:23 PM, David Holmes wrote:
>> On 6/03/2013 9:08 AM, Dean Long wrote:
>>> What if allocate_init_map() fails to allocate memory?  Shouldn't
>>> add_class_share_map_info() follow the pattern of add_map_info():
>>> return NULL or "map", and have the caller check for NULL?
>>
>> AFAICS apart from one seeming bug, if we can't allocate a new map it
>> does no harm in terms of the code that looks at the map. The bug is:
>>
>>  177    mp = ph->core->class_share_maps;
>>  178    if (mp) {
>>  179       print_debug("can't locate map_info at 0x%lx, trying class
>> share maps\n",
>>  180              addr);
>>
>> where I think 178 should be "if (mp==NULL)". Everything else will just
>> do nothing upon encountering a NULL map.
>>
>> The fix addresses the parfait warning and leaves the code functionally
>> unchanged. So any robustness issues would need to be done via a follow
>> up RFE.
>>
> Why not just add "return map" at the end of the function?  It seems
> closer to the intent of the original code, assuming it
> addresses the parfait warning.

Nothing expects a return value from that function so what point is there 
in returning something? I would expect that to simply produce another 
warning/error about a function return value being ignored.

David
-----

>
> dl
>
>> David
>>
>>> dl
>>>
>>> On 3/4/2013 11:39 PM, David Holmes wrote:
>>>> Looks fine to me - thanks Staffan!
>>>>
>>>> David
>>>>
>>>> On 5/03/2013 5:24 PM, Staffan Larsen wrote:
>>>>> A very small fix for a warning.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>
>>>
>


More information about the hotspot-dev mailing list