Fixed                
                
            
            
                
                    Created: Jun 5, 2016   
                                            Updated: Sep 8, 2018                                    
                
                    
                                    
             
         
        
            
            
                                    
                        Resolved Date: Jun 12, 2016                    
                
                
                                    
                        Found In Version: 7.0.0.15                     
                
                                    
                        Fix Version: 7.0.0.17                    
                
                                        
                            Severity: Standard                        
                    
                                        
                            Applicable for: Wind River Linux 7                        
                    
                                    
                        Component/s: Userspace                    
                
                
                             
         
                        
                We have now found new side effects with the patches.
Under high load and when using IPv6 we've found that named can crash with a segmentation fault. It crashes on a line inserted by the patches provided in this defect : LIN5-21257
Example of backtrace (unfortunately without libc debug symbols):
#0  0x00000036c380ab17 in ?? ()
#1  0x00007f34dbaec440 in ?? ()
#2  0x00000000004f9940 in resquery_destroy (queryp=0x7f34f41e4e78) at resolver.c:773
#3  0x00007f34dbaec440 in ?? ()
#4  0x00007f34f02d8850 in ?? ()
#5  0x00007f34f79f2028 in ?? ()
#6  0x00007f34f79f2088 in ?? ()
#7  0x00007f34f0309eb0 in ?? ()
#8  0x00000000004ff2a2 in process_sendevent (query=0x7f34dbaf2010, event=0x7f34f0309eb0) at resolver.c:1194
#9  0x00007f34f0309eb0 in ?? ()
#10 0x00007f34dbaf2010 in ?? ()
#11 0x00007f34f79f2010 in ?? ()
#12 0x000000000058a578 in dispatch (uap=0x7f34dbaf2010) at task.c:1012
#13 run (uap=0x7f34dbaf2010) at task.c:1157
#14 0x0000000000000000 in ?? () 
 
resolver.c with annotated line numbers with RCPL35+patches received from you:
 753 static inline void
 754 resquery_destroy(resquery_t **queryp) {
 755     dns_resolver_t *res;
 756     isc_boolean_t empty;
 757     resquery_t *query;
 758     fetchctx_t *fctx;
 759
 760     REQUIRE(queryp != NULL);
 761     query = *queryp;
 762     REQUIRE(!ISC_LINK_LINKED(query, link));
 763
 764     INSIST(query->tcpsocket == NULL);
 765
 766     fctx = query->fctx; 
 767     res = fctx->res;
 768
 769     fctx->nqueries--;
 770
 771     LOCK(&res->buckets[fctx->bucketnum].lock);
 772     empty = fctx_decreference(query->fctx);
 773     UNLOCK(&res->buckets[fctx->bucketnum].lock);
 774
 775     query->magic = 0;
 776     isc_mem_put(query->mctx, query, sizeof(*query));
 777     queryp = NULL;
 778
 779     if (empty)
 780         empty_bucket(res);
 781 }
 
We have found an upstream patch which seems to solve the issue, at least in initial testing:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c03fe78ef59b2373233db1a7b568cc2000d6d3b4
 
It seems like this patch was created not so long time after one of the commits, that were later backported to WRL5. Can you check if this patch is applicable in WRL5 (we believe so)? Possibly also if there are other patches affecting the backported commits?