This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
stackref warnings while running splint against gdb sources
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 2 Jun 2005 21:21:45 +0800 (CST)
- Subject: stackref warnings while running splint against gdb sources
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