Hi Joe, Sorry for the delays. Here is the diff. The replacement of the signal is to prevent false wakeups. It should be correct, but I can throw it through a modelchecker if you like?
Kind regards, Steven van der vegt -----Oorspronkelijk bericht----- Van: Joe Gooch [mailto:[email protected]] Verzonden: vrijdag 25 februari 2011 18:25 Aan: [email protected] Onderwerp: [Pound Mailing List] RE: Queue implementation errors? I looked at it and I agree, the crux of the problem seems to be the "next" variable in the tree isn't always populated. You moved the signal too... Not sure if that's right or not. Could provide your modified .c file so we could make a proper diff? Thanks. Joe > -----Original Message----- > From: Steven van der Vegt [mailto:[email protected]] > Sent: Friday, February 25, 2011 11:38 AM > To: [email protected] > Subject: [Pound Mailing List] RE: Queue implementation errors? > > Dear List, > > Can anyone comment on my proposed changes? > > Thanks! :) > > Steven > > -----Oorspronkelijk bericht----- > Van: Steven van der Vegt [mailto:[email protected]] > Verzonden: woensdag 16 februari 2011 17:40 > Aan: [email protected] > Onderwerp: [Pound Mailing List] Queue implementation errors? > > Hi Folks, > > I wanted to test the 2.6c version on a testsystem of ours but I ran > into trouble. Every time 1 request was handled I got this error: > > MONITOR: worker exited on signal 11, restarting... > > After some research I found out it was the memcopy in do_http() which > causes the error: > > from_host =arg *)arg)->from_host; > memcpy(&from_host_addr, from_host.ai_addr, from_host.ai_addrlen); > from_host.ai_addr =t sockaddr *)&from_host_addr; > > The value from_host.ai_addrlen was equal to 5394258 and after some > debugging it seems the whole struct contained bogus. > > Ok, let's find out why? > > The do_http() function is called from thr_http() which has some strange > while loop in it. It fetches work from a queue with the call > get_thr_arg() but this call is allowed to return a NULL value > sometimes. If this happens than ask again... > Well, this wasn't a NULL value so there must be something else going > on. Maybe the queue? > > The code contained some errors (as far as my concurrent and queue > knowledge go's). I reimplemented them to the following code. It solved > my errors and I think the strange while-loop in the thr_http function > is not needed anymore. > > Can you please comment on my changes? > > int > put_thr_arg(thr_arg *arg) > { > thr_arg *res; > > if((res =(sizeof(thr_arg))) = { > logmsg(LOG_WARNING, "thr_arg malloc"); > return -1; > } > memcpy(res, arg, sizeof(thr_arg)); > (void)pthread_mutex_lock(&arg_mut); > > res->next = > > if (last = { > first = > } else { > last->next > last > } > > pthread_cond_broadcast(&arg_cond); > (void)pthread_mutex_unlock(&arg_mut); > return 0; > } > > /* > * get a request from the queue > */ > thr_arg * > get_thr_arg(void) > { > thr_arg *res = > > (void)pthread_mutex_lock(&arg_mut); > while (first = > (void)pthread_cond_wait(&arg_cond, &arg_mut); > > res = > if((first =ext) = > last = > else > pthread_cond_signal(&arg_cond); > > (void)pthread_mutex_unlock(&arg_mut); > > return res; > } > > Thanks! > > Kind regards, > > Steven van der Vegt > > -- > To unsubscribe send an email with subject unsubscribe to > [email protected]. > Please contact [email protected] for questions. > > -- > To unsubscribe send an email with subject unsubscribe to > [email protected]. > Please contact [email protected] for questions. -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions. -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
