On Sat, Jul 26, 2014 at 01:22:01AM +0100, Chris Young wrote: > I have just discovered that > http://git.netsurf-browser.org/netsurf.git/tree/amiga/gui.c is using > ~450K of stack space. > > Visiting > http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup > uses just short of 1MB of stack. >
well that would seem to be excessive on any scale! > I don't know about the second link, but I'm sure it wasn't that long > ago when the top link was viewable in 256K of stack or maybe even > 128K. > I would have expected 64k or so at most but analysis of stack usage seems to be somewhat difficult. > I doubt much can be done about it, but am curious as to what has > changed to increase stack usage this much? > > Whilst NetSurf is usually pretty good at not going mad with the stack > (it usually sits at <64K), suddenly using 1MB on certain pages seems a > bit excessive. I have done an experiment with the gtk frontend which you migth want to do for amiga. add -fstack-usage to your CFLAGS in your Makefile.target and recompile from clean (needs gcc 4.6 or later) though this seems to interact badly with ccache so I just commented it out in netsurfs Makefile (line 307) this generates a lot of .su files in the build directory, I did: $ cat build-Linux-gtk/*.su | sort | sort -n -f -k2 |uniq which showed me the stack usage for each function in ascending order of size. about.c:724:13:fetch_about_can_fetch 16 static about.c:782:13:fetch_about_start 16 static about.c:788:13:fetch_about_abort 16 static base64.c:57:1:to_uchar 16 static bloom.c:105:10:bloom_items 16 static bloom.c:36:24:fnv 16 static ... curl.c:841:6:fetch_curl_done 6368 static gui.c:486:13:nsgtk_poll 8480 static urldb.c:346:6:urldb_load 9040 static urldb.c:3625:6:urldb_load_cookies 16608 static completion.c:38:10:nsgtk_completion_match 32816 static most of which does not seem exsessive (aside from urldb, which we already know "as a project" smells bad) so assuming amiga gets similar output I must conclude eiher we are recursing somewhere or something is dynamicaly allocating to the stack where it should not. My recent adventures looking at the ssl message issues (the corrupted treeviews on bad ssl certificates) do lead me to suspect some pages will cause our curl handling to dynamicly allocate several k on the stack, but nothing like the hundreds you are seeing. The recent move to scheduled callback out to (if anything) reduce stack usage as all calls are from the scheduler now serviced in each fontends poll loop which is a single function call down from the main function. if anyone else has more insights into this I would apreciate some input. -- Regards Vincent http://www.kyllikki.org/
