Program-assigned thread names on Windows

[LRN]

On 28.07.2016 0:35, Jon Turney wrote:
> 
> Doing a bit of testing with this patch...
> 
> On 26/07/2016 18:15, LRN wrote:
>> +	  named_thread = find_thread_ptid (named_thread_ptid);
> 
> ... it seems this may return NULL (e.g. if the thread we are naming was 
> short-lived and has already exited, or if the thread id was invalid) ...
> 
>> +
>> +	  thread_name = NULL;
>> +	  thread_name_len = target_read_string (thread_name_target, &thread_name, 1025, 0);
>> +	  if (thread_name_len > 0 && thread_name != NULL)
>> +	    {
>> +	      thread_name[thread_name_len - 1] = '\0';
>> +	      if (thread_name[0] != '\0')
>> +		{
>> +		  xfree (named_thread->name);
> 
> ... so this becomes a null dereference.
> 
>> +		  named_thread->name = thread_name;
>> +		}
>> +	      else
>> +		{
>> +		  xfree (thread_name);
>> +		}
> 

True.

The simplest fix for this is to turn the check
> thread_name[0] != '\0'
into
> thread_name[0] != '\0' && named_thread != NULL


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6759BA74.asc
Type: application/pgp-keys
Size: 3482 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160728/24392447/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160728/24392447/attachment.sig>