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