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

Dean Long dean.long at oracle.com
Tue Mar 5 17:37:01 PST 2013

On 3/5/2013 4:48 PM, David Holmes wrote:

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 allocateinitmap() fails to allocate memory? Shouldn't addclasssharemapinfo() follow the pattern of addmapinfo(): 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->classsharemaps; 178 if (mp) { 179 printdebug("can't locate mapinfo 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. If it complains about that then wouldn't we need to put (void) in front of all calls to strcat(), for example? Anyway, I'm OK with the current change if Staffan files an RFE for other issue.

dl

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