September 2013 - Dillo-dev - lists.mailman3.com

compilation error in fltkflatview.cc

by csoren＠isd.net

Greets all, As I've mentioned previously I'm trying to compile dillo-3.0.3 on Silicon Graphics using the SGI MIPSpro compiler. I'm doing this for a large group of SGI users who reside at nekochan.net. The compilation fails in line 884 in fltkflatview.cc: ---------- cc-3168 CC: ERROR File = fltkui.cc, Line = 884 A name followed by "::" must be a class or namespace name. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 884 "dw::fltk::ui::FltkToggleButtonResource<I>::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ 2 errors detected in the compilation of "fltkflatview.cc". ---------- I suspect it needs a 'using namespace' or somesuch here, thoughts? Thanks a bunch!

Sept. 2, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

On Sun, Sep 01, 2013 at 08:49:06PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Aug 30, 2013 at 12:41:41PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, JG: > > > > On Thu, Aug 29, 2013 at 09:13:49AM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > > > > Hi JG, > > > > > > > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > > > > are not reaped when they terminate themselves after a period of > > > > > > inactivity while the parent dillo process is still running. The patch > > > > > > below is simply to reap these zombies. The SIGCHLD handler should > > > > > > probably do more, but I am not yet familiar enough with Dillo to know > > > > > > what. > > > > > > > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > > > > am new to the list and a novice at Dillo patching. And hence also > > > > > > apologies to Jorge for this duplication of a previous communication by > > > > > > private email (although with one small change to get the patch to > > > > > > compile under OpenBSD as well as Linux). > > > > > > > > > > I can reproduce the issue here by killing dpid manually. > > > > > For me the following also fixes it: > > > > > > > > > > diff -r 659dc205c377 src/dillo.cc > > > > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > > > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > > > > @@ -329,6 +329,7 @@ > > > > > > > > > > // Some OSes exit dillo without this (not GNU/Linux). > > > > > signal(SIGPIPE, SIG_IGN); > > > > > + signal(SIGCHLD, SIG_IGN); > > > > > > > > > > /* Handle command line options */ > > > > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > > > > > > > Can you please check whether it works for you too? It would have the > > > > > advantage that we have all signal related stuff in one place. > > > > > > > > Oh, I'm looking at it now too! > > > > For me this is an old TODO: with subtle issues lurking. > > > > > > > > > > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > > > > > > > > > > After some digging (Manual page sigaction(2)): > > > > > > > > ... > > > > > > > > "A child created via fork(2) inherits a copy of its parent's > > > > signal dispositions. During an execve(2), the dispositions of > > > > handled signals are reset to the default; the dispositions of > > > > ignored signals are left unchanged." > > > > > > I guess this is no problem, as dpid explicitely adds a signal > > > handler for SIGCHLD again, but I'm happy if you take care of the > > > whole issue :-) > > > > The attached program is a stress test for SIGCHLD. The idea is to > > find a formula that works well even in such cases. IIRC both of you > > have access to BSD machines so please test it there. > > > > The program spawns 255 children which sleep 5 seconds and > > terminate generating a SIGCHLD avalanche, which should be handled > > cleanly. It works OK in Debian. > > > > $gcc -W -Wall sigcld.c -o sigcld > > $./sigcld > > > > in another terminal (during the 5 secs. sleep window): > > > > $ps aux|grep sigcld > > > > (shows the long list) > > > > then while main is Sleeping 10 seconds: > > > > $ps aux|grep sigcld > > > > (shows only one sigcld process) > > > > after it exits: > > > > $ps aux|grep sigcld > > > > (no process left) > > Works fine on DragonFlyBSD with the #include <wait.h> line removed. Good! I'll patch and commit soon. -- Cheers Jorge.-

Sept. 1, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Aug 30, 2013 at 12:41:41PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, JG: > > On Thu, Aug 29, 2013 at 09:13:49AM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > > > Hi JG, > > > > > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > > > are not reaped when they terminate themselves after a period of > > > > > inactivity while the parent dillo process is still running. The patch > > > > > below is simply to reap these zombies. The SIGCHLD handler should > > > > > probably do more, but I am not yet familiar enough with Dillo to know > > > > > what. > > > > > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > > > am new to the list and a novice at Dillo patching. And hence also > > > > > apologies to Jorge for this duplication of a previous communication by > > > > > private email (although with one small change to get the patch to > > > > > compile under OpenBSD as well as Linux). > > > > > > > > I can reproduce the issue here by killing dpid manually. > > > > For me the following also fixes it: > > > > > > > > diff -r 659dc205c377 src/dillo.cc > > > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > > > @@ -329,6 +329,7 @@ > > > > > > > > // Some OSes exit dillo without this (not GNU/Linux). > > > > signal(SIGPIPE, SIG_IGN); > > > > + signal(SIGCHLD, SIG_IGN); > > > > > > > > /* Handle command line options */ > > > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > > > > > Can you please check whether it works for you too? It would have the > > > > advantage that we have all signal related stuff in one place. > > > > > > Oh, I'm looking at it now too! > > > For me this is an old TODO: with subtle issues lurking. > > > > > > > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > > > > > > > After some digging (Manual page sigaction(2)): > > > > > > ... > > > > > > "A child created via fork(2) inherits a copy of its parent's > > > signal dispositions. During an execve(2), the dispositions of > > > handled signals are reset to the default; the dispositions of > > > ignored signals are left unchanged." > > > > I guess this is no problem, as dpid explicitely adds a signal > > handler for SIGCHLD again, but I'm happy if you take care of the > > whole issue :-) > > The attached program is a stress test for SIGCHLD. The idea is to > find a formula that works well even in such cases. IIRC both of you > have access to BSD machines so please test it there. > > The program spawns 255 children which sleep 5 seconds and > terminate generating a SIGCHLD avalanche, which should be handled > cleanly. It works OK in Debian. > > $gcc -W -Wall sigcld.c -o sigcld > $./sigcld > > in another terminal (during the 5 secs. sleep window): > > $ps aux|grep sigcld > > (shows the long list) > > then while main is Sleeping 10 seconds: > > $ps aux|grep sigcld > > (shows only one sigcld process) > > after it exits: > > $ps aux|grep sigcld > > (no process left) Works fine on DragonFlyBSD with the #include <wait.h> line removed. Cheers, Johannes

Sept. 1, 2013