From: Wu Zhou <woodzltc@cn.ibm.com>
To: gdb@sources.redhat.com
Subject: stackref warnings while running splint against gdb sources
Date: Thu, 02 Jun 2005 13:26:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.63.0506022106430.16887@plinuxt18.cn.ibm.com> (raw)
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
reply other threads:[~2005-06-02 13:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.63.0506022106430.16887@plinuxt18.cn.ibm.com \
--to=woodzltc@cn.ibm.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).