- Dillo-dev - lists.mailman3.com

dw::Table valgrind-friendliness

by Johannes.Hofmann＠gmx.de

On Sun, Mar 02, 2008 at 02:57:14PM +0000, Jeremy Henty wrote: > On Sun, Mar 02, 2008 at 02:43:56PM +0000, Jeremy Henty wrote: > > On Sun, Mar 02, 2008 at 11:31:16AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > > > > > > > Dillo has been neglecting its valgrind cleanliness recently and > > > > it turns out the culprit is dw::Table, which resizes its > > > > internal vectors without initialising any new values that > > > > appear. > > > > > > AFAIU, this patch covers the symptoms of a BUG that current CVS > > > fixes. Please test current CVS against valgrind. > > > > No change. 121 "Conditional jump..." errors, reduced to 2 by my > > patch. > > To explain, these errors appear because the code updates the entries > of the cumHeight and colWidths vectors with wrapper methods > setCumHeight and setColWidth. These wrappers begin by comparing the > new value with old one and branching on the result, so you get the > "Conditional jump..." errors whenever the old value was not > initialized. That means these errors have nothing to do with any of > the Table algorithms, they're entirely due to the way the Table code > manages the cumHeight and colWidths vectors. These wrapper methods were introduced by my redraw patch. I will fix this. Johannes > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 02:43:56PM +0000, Jeremy Henty wrote: > On Sun, Mar 02, 2008 at 11:31:16AM -0300, Jorge Arellano Cid wrote: > > On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > > > > > Dillo has been neglecting its valgrind cleanliness recently and > > > it turns out the culprit is dw::Table, which resizes its > > > internal vectors without initialising any new values that > > > appear. > > > > AFAIU, this patch covers the symptoms of a BUG that current CVS > > fixes. Please test current CVS against valgrind. > > No change. 121 "Conditional jump..." errors, reduced to 2 by my > patch. To explain, these errors appear because the code updates the entries of the cumHeight and colWidths vectors with wrapper methods setCumHeight and setColWidth. These wrappers begin by comparing the new value with old one and branching on the result, so you get the "Conditional jump..." errors whenever the old value was not initialized. That means these errors have nothing to do with any of the Table algorithms, they're entirely due to the way the Table code manages the cumHeight and colWidths vectors. Jeremy Henty

March 2, 2008

dw::Table valgrind-friendliness

by Johannes.Hofmann＠gmx.de

Hi Jeremy, can you please send the valgrind log? Johannes On Sun, Mar 02, 2008 at 02:43:56PM +0000, Jeremy Henty wrote: > On Sun, Mar 02, 2008 at 11:31:16AM -0300, Jorge Arellano Cid wrote: > > On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > > > > > Dillo has been neglecting its valgrind cleanliness recently and it > > > turns out the culprit is dw::Table, which resizes its internal > > > vectors without initialising any new values that appear. > > > > AFAIU, this patch covers the symptoms of a BUG that current CVS > > fixes. Please test current CVS against valgrind. > > No change. 121 "Conditional jump..." errors, reduced to 2 by my > patch. > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 11:31:16AM -0300, Jorge Arellano Cid wrote: > On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > > > Dillo has been neglecting its valgrind cleanliness recently and it > > turns out the culprit is dw::Table, which resizes its internal > > vectors without initialising any new values that appear. > > AFAIU, this patch covers the symptoms of a BUG that current CVS > fixes. Please test current CVS against valgrind. No change. 121 "Conditional jump..." errors, reduced to 2 by my patch. Jeremy Henty

March 2, 2008

Fixed a mistake in the CSS-box-model PNG image (style-box-model.png).

by jcid＠dillo.org

Hi, I just committed this fix. The wrong documentation image mislead me a lot while working on the redraw problems. Now it's accurate (CSS box model in namespacedw_1_1core_1_1style.html). -- Cheers Jorge.-

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 02:15:39PM +0000, I wrote: > Dillo has been neglecting its valgrind cleanliness recently and it > turns out the culprit is dw::Table, ... Oops, I missed one! Here's a followup patch for consistency. Jeremy Henty

March 2, 2008

dw::Table valgrind-friendliness

by jcid＠dillo.org

On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > Dillo has been neglecting its valgrind cleanliness recently and it > turns out the culprit is dw::Table, which resizes its internal vectors > without initialising any new values that appear. If you valgrind > dillo and immediately close the splash window, valgrind reports 121 > "Conditional jump or move depends on uninitialised value" errors! > This patch reduces that number to 2! AFAIU, this patch covers the symptoms of a BUG that current CVS fixes. Please test current CVS against valgrind. -- Cheers Jorge.-

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

Dillo has been neglecting its valgrind cleanliness recently and it turns out the culprit is dw::Table, which resizes its internal vectors without initialising any new values that appear. If you valgrind dillo and immediately close the splash window, valgrind reports 121 "Conditional jump or move depends on uninitialised value" errors! This patch reduces that number to 2! Regards, Jeremy Henty

March 2, 2008

a drawing segfault

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 06:30:03AM +0000, place wrote: > I was just opening file:///tmp/, which is not normally a problem... > > *** [unknown] Assertion failed! *** > Array index out of bounds: 28 >= 28 > > Program received signal SIGABRT, Aborted. I see this occasionally too, though it seems to be sporadic. I can't figure what the trigger is. Does it happen every time you open the directory or only occasionally? Jeremy Henty

March 2, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

Hi, On Sun, Mar 02, 2008 at 01:25:28AM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 29, 2008 at 10:37:04PM +0000, place wrote: > > > > Have you tried something like?: > > > > > > > > </pseudocode> > > > > > > > > Html_submit_form2() > > > > ... > > > > if (ENC_MULTIPART) { > > > > append every single "name" "value" pair into a Dstr > > > > do { > > > > make boundary > > > > } while (strstr(Dstr, boundary) || maxtries); > > > > } > > > > ... > > > > encode as usual. > > > > > > > > </pseudocode> > > I gave it a try and ended up with the attached compiles-but-hardly-tested > code. I had somehow forgotten earlier that I was going to have to use > Dlists of values due to SELECT elements. > > This runs through the inputs once for boundary creation, and > a second time for url->data creation. > > I was tempted to try > - go through once, making a Dlist of name/value pairs > - if (MULTIPART) determine a boundary, strstr()ing names and values > - give each pair in the Dlist to Html_append_input > but that's no good because I wouldn't know whether I had data from > a file input when making url->data (Content-Disposition is different). > > > Thoughts? Yes. As form-submitting is not a frequent operartion, much less with multipart, there's no compelling need to optimize it further. This version of the patch is easier to read and understand. Please comment the Html_get_input_values() function. For: > + // BUG: strstr stops at NULL. Cannot use for file inputs. > + success = !strstr(DataStr->str, boundary->str); please use memcmp(). Some basic testing would be welcomed, but the main probe will be done by usage when committed. -- Cheers Jorge.-

March 2, 2008