bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] kern/processor.c: check if threads is NULL


From: Samuel Thibault
Subject: Re: [PATCH 3/5] kern/processor.c: check if threads is NULL
Date: Tue, 19 Nov 2013 20:49:37 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Marin Ramesa, le Tue 19 Nov 2013 07:34:21 +0100, a écrit :
> When addr is equal to zero, array access from pointer threads
> results in a dereference of null pointer. Avoid this by checking
> if it's NULL.

This is a false positive: what the analyzer doesn't know is that
pset->thread_count is number of elements in the pset->threads queue.
I.e. actual is only ever set to 0 when the pset->threads queue is empty,
and thus no iteration of the loop is done.

> * kern/processor.c (threads): Check if it's NULL.
> 
> ---
>  kern/processor.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kern/processor.c b/kern/processor.c
> index 0cb9974..9da06f5 100644
> --- a/kern/processor.c
> +++ b/kern/processor.c
> @@ -924,7 +924,8 @@ processor_set_things(
>                    thread = (thread_t) queue_next(&thread->pset_threads)) {
>                       /* take ref for convert_thread_to_port */
>                       thread_reference(thread);
> -                     threads[i] = thread;
> +                     if (threads != (thread_t *)0)
> +                             threads[i] = thread;

This kind of fix would almost never be a proper one: as I explained
earlier, you have to look with a more global view: start with the
tracing exposed on the analysis webpage, which shows where things come
from: the actual variable. And that's where we know it can't happen.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]