- Dillo-dev - lists.mailman3.com

dillo-3.0-rc2 is out

by corvid＠lavabit.com

We'll need to make a point of mentioning -- at least in the release announcement, and maybe in README -- how specifying fonts is a little trickier now with fltk-1.3. I wouldn't be surprised if we end up having to try to get fltk to add another interface of some sort so that those of us who care about fonts and have a lot of them (i.e., not me) can have font-family work more consistently.

Aug. 30, 2011

valgrind still unhappy despite expect changes

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > -O0"' to minimise false positives from gcc optimization. > > Ack. > > Given you got the log. Do you have a way to reproduce it, or at > least have a memory of what you were doing? Unfortunately no. I automatically run dillo inside valgrind and log the output. A cron job reads the logs and updates the reports. These days I rarely even look at the logs unless something in the mailing list prompts me to. I am wondering how to add debugging information that could help tie valgrind reports to Dillo's actions. Perhaps the CCC could log which of its chains is active and which URL it was serving? Then if dlib logged its allocations and frees maybe we could identify the URL that was responsible? Regards, Jeremy Henty

Aug. 30, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Tue, Aug 30, 2011 at 12:01:41AM +0200, Axel Beckert wrote: > Hi, > > On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote: > > Today the rc2 was packaged. Please get it here: > > > > http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball > > Hrm, the tar ball doesn't contain the autogen.sh script I used for the > Debian packaging. (I build the last two package against the hg > checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) > Is that file not included on purpose? Yes, autogen.sh uses auto* tools to rebuild the configure script, but the configure script is included in the tarball. It is not in the repository because different auto*tools in different platforms generate slightly different configure scripts leading to almost one configure update per commit... > At least in the README, the instructions still say: > > tar jxvf dillo-3.0.tar.bz2 > cd dillo-3.0 > ./autogen.sh; ./configure; make > sudo make install-strip > > OTOH the INSTALL document skips that step, but AFAICS it never has > been changed since the import into the Mercurial repository while the > README has changed a lot in the "Minor changes for dillo-3.0-rc2" > commit. > > Looks inconsistent to me. Not sure which variant is the intended one. Right. Fixed in the repo to read: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./configure; make sudo make install-strip -- Cheers Jorge.-

Aug. 30, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

Hi Jeremy, Good to see you in this thread! On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > > OTOH, valgrind produces some false positives (its docs say it) and > > gcc optimization can also play a role... > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g -O0"' to > minimise false positives from gcc optimization. Ack. Given you got the log. Do you have a way to reproduce it, or at least have a memory of what you were doing? -- Cheers Jorge.-

Aug. 30, 2011

valgrind still unhappy despite expect changes

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > OTOH, valgrind produces some false positives (its docs say it) and > gcc optimization can also play a role... I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g -O0"' to minimise false positives from gcc optimization. Regards, Jeremy Henty

Aug. 30, 2011

dillo-3.0-rc2 is out

by abe＠deuxchevaux.org

Hi, On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote: > Today the rc2 was packaged. Please get it here: > > http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball Hrm, the tar ball doesn't contain the autogen.sh script I used for the Debian packaging. (I build the last two package against the hg checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) Is that file not included on purpose? At least in the README, the instructions still say: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./autogen.sh; ./configure; make sudo make install-strip OTOH the INSTALL document skips that step, but AFAICS it never has been changed since the import into the Mercurial repository while the README has changed a lot in the "Minor changes for dillo-3.0-rc2" commit. Looks inconsistent to me. Not sure which variant is the intended one. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 30, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

Hi there, After: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak Today the rc2 was packaged. Please get it here: http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball http://dillo.org/download/dillo-3.0-pre.tar.bz2.asc // signature The idea is to test the package in different OS/HW-Platforms and to report how the build process went, and how it works. Hopefully it'll become dillo-3.0. Afterall, it has been for a long enough time in testing phase. TIA for your feedback. -- Last but not the least: [ok] valgrind logs: cancel expected url I can't reproduce this anymore (after the committed fix). If somebody can still reproduce it, please report it. Details are in this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008810.html (the "expected url" is the one you've asked for but whose data bytes haven't started to arrive. If during this period of time you stop the request --e.g. by pressing Stop or clicking another URL, it's cancelled--). -- Cheers Jorge.-

Aug. 29, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > > > No valgrind error report before or after these debug messages: > > > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > > Dillo: normal exit! > > > > > > I tested by pushing a remote URL on CLI and closing the window > > > before the page data starts flowing (i.e. to cancel the > > > "expect"), and also with the cancelled download code path. > > > Neither one produced an error. > > > > I saw that there was another log entry the other day > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > Do you think something sneaky could be going on, or does it seem > > like it must come down to configuration differences somehow? > > AFAIS, either one is possible... > > Me not being able to reproduce it says it's most probably be OK > for the codepaths I tested (FWIW, the ones I can see). If there's > an untested codepath, well... > > OTOH, valgrind produces some false positives (its docs say it) > and gcc optimization can also play a role... > > So, I'd try to find a simple test case that produces the log. > Then, test this problematic codepath here, and see what comes out > of the exercise. > > Can you reproduce the bug? Do you have a simple test case? No. I haven't really scrutinized the code at all. I've tried a little "I wonder whether this could do it" just from looking at the traces supplied by valgrind, but without hitting upon the trick.

Aug. 29, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > No valgrind error report before or after these debug messages: > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > Dillo: normal exit! > > > > I tested by pushing a remote URL on CLI and closing the window > > before the page data starts flowing (i.e. to cancel the > > "expect"), and also with the cancelled download code path. > > Neither one produced an error. > > I saw that there was another log entry the other day > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > Do you think something sneaky could be going on, or does it seem > like it must come down to configuration differences somehow? AFAIS, either one is possible... Me not being able to reproduce it says it's most probably be OK for the codepaths I tested (FWIW, the ones I can see). If there's an untested codepath, well... OTOH, valgrind produces some false positives (its docs say it) and gcc optimization can also play a role... So, I'd try to find a simple test case that produces the log. Then, test this problematic codepath here, and see what comes out of the exercise. Can you reproduce the bug? Do you have a simple test case? -- Cheers Jorge.-

Aug. 29, 2011

valgrind doctree leak

by Johannes.Hofmann＠gmx.de

On Sun, Aug 28, 2011 at 02:02:18AM +0000, corvid wrote: > > (from Jeremy's logs) > > ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 > ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) > ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) > ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) > ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) > ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) > ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) > ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) > ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) > ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) > ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x804F08A: main (dillo.cc:436) These valgrind log's are really helpful! Should be fixed now.

Aug. 28, 2011