stackref warnings while running splint against gdb sources

stackref warnings while running splint against gdb sources

[Wu Zhou]

Hello all,

I am recently running splint against gdb sources and found some stackref
warnings which might interested you. (In splint context, "stackref" means
that a stack reference is pointed to by an external reference when the 
function returns. The stack-allocated storage is destroyed after the call, 
thus leaving a dangling reference. )

IMHO, to determine whether these stackref will make trouble at all, we 
need to analyze how that external reference will be used in later code.  
So I have some initial analysis on these and report them here.  Would
anyone like to take some look?  Any suggestion and comments are highly 
appreciated!

1. gdb/breakpoint.c: (in function bpstat_get_triggered_catchpoints)

breakpoint.c:3265:2: Stack-allocated storage *cp_list reachable from parameter cp_list
  breakpoint.c:3264:3: Storage *cp_list becomes stack-allocated storage

The above is what splint reports and related code is listed below:

void
bpstat_get_triggered_catchpoints (bpstat ep_list, bpstat *cp_list)
{
  struct bpstats root_bs[1];
  bpstat bs = root_bs;	====> stack-allocated variable
...
  *cp_list = bs;	====> line 3264, cp_list becomes stackref here
}								  

In this case, bpstat_get_triggered_catchpoints is called in function 
handle_inferior_event of infrun.c like this:

	bpstat_get_triggered_catchpoints (stop_bpstat,		
			&ecs
			->stepping_through_solib_catchpoints);
						
so ecs->stepping_through_solib_catchpoints will become a stack reference 
after the above call return.  And it will be read later in the same 
function, so the data it refer to might get dangled.  IMO, this should 
be fixed.  Maybe I could code a patch on this.  Any thought on this?  

BTW, I am also thinking about in which real case this code will be 
executed, but don't get any idea yet.  Is there anybody could help on 
this?  Thanks.

P.S: to make this mail shorter, I will post another two anlyses in other 
mails.

Cheers
- Wu Zhou