March 2008 - Dillo-dev - lists.mailman3.com

segfault in Html_submit_form2()

by place＠gobigwest.com

Johannes wrote: > It was crashing on every form submit I tried (e.g. www.google.com) Hmm. Too bad I'm still on old Linux. (I looked at DragonflyBSD some months ago, by the way, and was disappointed that I couldn't install from a file on the hard drive. I don't even have a CD writer.) > I also got a compiler warning: > > html.cc:3945: warning: 'boundary' may be used uninitialized in this function I wasn't getting a warning, but this brings up something I've been meaning to ask: Jorge, what do you think of -Werror? So far as I can recall, the only warning on the dillo2/ side currently is Html_input_image. It would save me the trouble of monitoring compilation...

March 3, 2008

patch: Re: [Dillo-dev] segfault in Html_submit_form2()

by jcid＠dillo.org

Hi, On Mon, Mar 03, 2008 at 05:28:36PM +0000, place wrote: > > after updating to latest CVS, I got the following segfault when > > submitting a simple form: > > Oops! Thanks, Johannes. Patch attached. > I had the code doing the right thing at some point in the past after it > crashed once on me, but then I forgot why I'd made the change and undid it :( FWIW, this patch changes the API of Html_append_input: - Html_append_input(DilloHtmlEnc encoding, const char *boundary, Dstr *url, + Html_append_input(DilloHtmlEnc encoding, Dstr *boundary, Dstr *url, Current CVS has a different patch that fixes the segfault. The question is, do you want me to commit the API change too? -- Cheers Jorge.-

March 3, 2008

patch: Re: [Dillo-dev] segfault in Html_submit_form2()

by place＠gobigwest.com

> after updating to latest CVS, I got the following segfault when > submitting a simple form: Oops! Thanks, Johannes. Patch attached. I had the code doing the right thing at some point in the past after it crashed once on me, but then I forgot why I'd made the change and undid it :( What was the URL?

March 3, 2008

segfault in Html_submit_form2()

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Mar 03, 2008 at 02:04:25PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Mon, Mar 03, 2008 at 05:16:51PM +0100, Johannes Hofmann wrote: > > Hi, > > > > after updating to latest CVS, I got the following segfault when > > submitting a simple form: > > > [...] > > I think the problem is, that boundary only gets initialized if > > form->enc == DILLO_HTML_ENC_MULTIPART. > > It doesn't segfault for me. Anyway I committed a small fix. > Please test and post the URL that was triggering the bug. Yes, that fixes it. It was crashing on every form submit I tried (e.g. www.google.com) I also got a compiler warning: html.cc:3945: warning: 'boundary' may be used uninitialized in this function Cheers, Johannes > > TIA. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 3, 2008

segfault in Html_submit_form2()

by jcid＠dillo.org

Hi Johannes, On Mon, Mar 03, 2008 at 05:16:51PM +0100, Johannes Hofmann wrote: > Hi, > > after updating to latest CVS, I got the following segfault when > submitting a simple form: > [...] > I think the problem is, that boundary only gets initialized if > form->enc == DILLO_HTML_ENC_MULTIPART. It doesn't segfault for me. Anyway I committed a small fix. Please test and post the URL that was triggering the bug. TIA. -- Cheers Jorge.-

March 3, 2008

segfault in Html_submit_form2()

by Johannes.Hofmann＠gmx.de

Hi, after updating to latest CVS, I got the following segfault when submitting a simple form: Program terminated with signal 11, Segmentation fault. #0 0x0805de09 in a_Html_form_event_handler (data=0x28794400, form_receiver=0x28835620, v_resource=0x28841000) at html.cc:4006 4006 input->name, val->str); (gdb) bt #0 0x0805de09 in a_Html_form_event_handler (data=0x28794400, form_receiver=0x28835620, v_resource=0x28841000) at html.cc:4006 #1 0x0805b301 in form::Form::activate (this=0x28835620, resource=0x28841000) at form.cc:100 #2 0x0808e6f7 in dw::core::ui::Resource::ActivateEmitter::emitToReceiver ( this=0x28841008, receiver=0x28835628, signalNo=0, argc=2, argv=0xbfbff15c) at ui.cc:101 #3 0x08093886 in loutsignal::Emitter::emitVoid (this=0x28841008, signalNo=0, argc=2, argv=0xbfbff15c) at signal.cc:81 #4 0x0808e727 in dw::core::ui::Resource::ActivateEmitter::emitActivate (this=0x28841008, resource=0x28841000) at ui.cc:109 #5 0x080aa945 in fltk::Input::handle_key () #6 0x080aadde in fltk::Input::handle () #7 0x080ab0d4 in fltk::Input::handle () #8 0x080ceddb in fltk::Widget::send () #9 0x080b67e4 in fltk::handle () #10 0x080b9bfb in fltk::handle () #11 0x080bb16b in do_queued_events () #12 0x080bb3ad in fltk::wait () #13 0x080bb55d in fltk::run () I think the problem is, that boundary only gets initialized if form->enc == DILLO_HTML_ENC_MULTIPART. Cheers, Johannes

March 3, 2008

dw::Table valgrind-friendliness

by jcid＠dillo.org

On Sun, Mar 02, 2008 at 09:23:53PM +0100, Johannes Hofmann wrote: > On Sun, Mar 02, 2008 at 03:45:09PM +0000, Jeremy Henty wrote: > > On Sun, Mar 02, 2008 at 04:14:00PM +0100, Johannes Hofmann wrote: > > > > > I think your proposed fix is fine. It's just that I don't like the > > > wrapper methods too much in the first place and now we need even > > > more code to support it... > > > > I'm not particularly attached to my proposed fix, my real concern is > > being valgrind clean because anything that makes valgrind harder to > > use is bad news. My patch was just the simplest way I could see to > > achieve that. If there's a better way to do it then that's great! > > > > ok, here is my proposal. It reduces the additional code in table.cc > a bit. Thanks to Jeremy for testing with valgrind. OK, committed. Please beware that this may cloak bugs. It was due to an assertion from the old code that the Table::draw() bug was found: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003837.html > Thanks to Jeremy for testing with valgrind. Ditto. -- Cheers Jorge.-

March 3, 2008

Re: patch: boundary for multipart/form-data submission with zero parts

by jcid＠dillo.org

Hi, On Sun, Mar 02, 2008 at 07:05:08PM +0000, place wrote: > Looking again at rfc 2046, I notice that an empty boundary string is not legal. > > As for what to do in the body in that case, it's conceivable that a lifetime > of digging through RFCs would yield a definitive answer for a weird > corner case, but it's far from being worth the trouble... > (Firefox sends a body consisting of an ending boundary line "--[boundary]--") Committed. -- Cheers Jorge.-

March 3, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

Hi, On Sun, Mar 02, 2008 at 09:20:53PM +0000, place wrote: > > For: > > > > > + // BUG: strstr stops at NULL. Cannot use for file inputs. > > > + success = !strstr(DataStr->str, boundary->str); > > > > please use memcmp(). > > How about if I make a separate patch for that at some point with > a Dstr_memmem() or something like that? OK. > > Some basic testing would be welcomed, but the main probe will > > be done by usage when committed. > > I added some comments, > changed the size of my dList_new() because the old value -- a holdover > from when I thought I'd do it differently -- could mislead the unwary, > and moved the dStr_free(boundary) down a little, > but this version should have no functional changes from the > version sent to the list yesterday. Committed. -- Cheers Jorge.-

March 3, 2008

dw::Table valgrind-friendliness

by Johannes.Hofmann＠gmx.de

On Sun, Mar 02, 2008 at 03:45:09PM +0000, Jeremy Henty wrote: > On Sun, Mar 02, 2008 at 04:14:00PM +0100, Johannes Hofmann wrote: > > > I think your proposed fix is fine. It's just that I don't like the > > wrapper methods too much in the first place and now we need even > > more code to support it... > > I'm not particularly attached to my proposed fix, my real concern is > being valgrind clean because anything that makes valgrind harder to > use is bad news. My patch was just the simplest way I could see to > achieve that. If there's a better way to do it then that's great! > ok, here is my proposal. It reduces the additional code in table.cc a bit. Thanks to Jeremy for testing with valgrind. Johannes diff -r 4582dc80e696 dw/table.cc --- a/dw/table.cc Sun Mar 02 13:40:23 2008 +0100 +++ b/dw/table.cc Sun Mar 02 21:21:17 2008 +0100 @@ -516,8 +516,8 @@ void Table::forceCalcCellSizes () printf(" totalWidth2 = %d curCol=%d\n", totalWidth,curCol); #endif - colWidths->setSize (numCols); - cumHeight->setSize (numRows + 1); + colWidths->setSize (numCols, 0); + cumHeight->setSize (numRows + 1, 0); rowSpanCells->setSize (0); baseline->setSize (numRows); #ifdef DBG @@ -857,7 +857,7 @@ void Table::apportion2 (int totalWidth, if (!maxAutoWidth) // no LEN_AUTO cols! return; - colWidths->setSize (colExtremes->size ()); + colWidths->setSize (colExtremes->size (), 0); if (!forceTotalWidth && maxAutoWidth < availAutoWidth) { // Enough space for the maximum table, don't widen past max. diff -r 4582dc80e696 lout/misc.hh --- a/lout/misc.hh Sun Mar 02 13:40:23 2008 +0100 +++ b/lout/misc.hh Sun Mar 02 21:21:17 2008 +0100 @@ -161,6 +161,18 @@ public: inline void setSize(int newSize) { this->num = newSize; this->resize (); } /** + * \brief Set the size explicitely and initialize new values. + * + * May be necessary before called before misc::SimpleVector::set. + */ + inline void setSize (int newSize, T t) { + int oldSize = this->num; + setSize (newSize); + for (int i = oldSize; i < newSize; i++) + set (i, t); + } + + /** * \brief Return the reference of one element. * * \sa misc::SimpleVector::get

March 2, 2008