On Sun, Apr 24, 2016 at 09:15:42PM +0200, Sebastian Geerken wrote:
On Tue, Apr 19, 2016, eocene wrote:
Here's a segfault backtrace that I just got:
#0 0x080ab83d in dw::Textblock::sizeRequestReference (this=0x955e260, index=-1224641713) at textblock.cc:423 #1 0x080bcd63 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::numParts ( this=0x9e446a8, sectionIndex=-1, numContentsInFlow=0) at oofawarewidget_iterator.cc:84
I do not understand what has actually happens (look at the code). Did you compile dillo with -O2 or -O0? Can you provide a test case how this is reproduced?
Perhaps this is related to another prolem: valgrind prints some warnings, which neither make sense to me.
As I recall, I was double-checking whether the textarea row attr default was still 2 in html5 (https://www.w3.org/TR/html51/sec-forms.html#the-textarea-element) searching for "rows ". But when I try this again, it doesn't crash. FWIW, I compiled with -O0. *tries valgrind* I do get a number of "Conditional jump or move depends on uninitialised value(s)" when the page loads. Searching the page doesn't cause any more, though.
On Sun, Apr 24, 2016 at 10:02:13PM +0000, eocene wrote:
On Sun, Apr 24, 2016 at 09:15:42PM +0200, Sebastian Geerken wrote:
On Tue, Apr 19, 2016, eocene wrote:
Here's a segfault backtrace that I just got:
#0 0x080ab83d in dw::Textblock::sizeRequestReference (this=0x955e260, index=-1224641713) at textblock.cc:423 #1 0x080bcd63 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::numParts ( this=0x9e446a8, sectionIndex=-1, numContentsInFlow=0) at oofawarewidget_iterator.cc:84
I do not understand what has actually happens (look at the code). Did you compile dillo with -O2 or -O0? Can you provide a test case how this is reproduced?
Perhaps this is related to another prolem: valgrind prints some warnings, which neither make sense to me.
As I recall, I was double-checking whether the textarea row attr default was still 2 in html5 (https://www.w3.org/TR/html51/sec-forms.html#the-textarea-element) searching for "rows ". But when I try this again, it doesn't crash.
FWIW, I compiled with -O0.
*tries valgrind* I do get a number of "Conditional jump or move depends on uninitialised value(s)" when the page loads.
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity. If I run under valgrind, I get: ==9344== Conditional jump or move depends on uninitialised value(s) ==9344== at 0x80A4493: dw::oof::OOFPositionedMgr::sizeAllocateStart(dw::oof::OOFAwareWidget*, dw::core::Allocation*) (oofpositionedmgr.cc:78) ==9344== by 0x809F7E6: dw::oof::OOFAwareWidget::sizeAllocateStart(dw::core::Allocation*) (oofawarewidget.cc:347) ==9344== by 0x80ABDB6: dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) (textblock.cc:585) ==9344== by 0x80E0DAD: dw::core::Widget::sizeAllocate(dw::core::Allocation*) (widget.cc:1135) ==9344== by 0x80D3D77: dw::core::Layout::resizeIdle() (layout.cc:924) ==9344== by 0x80C1B63: dw::fltk::FltkPlatform::generalIdle() (fltkplatform.cc:630) ==9344== by 0x80C1AEB: dw::fltk::FltkPlatform::generalStaticIdle(void*) (fltkplatform.cc:620) ==9344== by 0x4120CDB: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x4691E45: (below main) (libc-start.c:244) ==9344== ==9344== Invalid read of size 4 ==9344== at 0x80BCFA7: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart(int, int, dw::core::Content*) (oofawarewidget_iterator.cc:102) ==9344== by 0x80BD27D: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev() (oofawarewidget_iterator.cc:204) ==9344== by 0x80D0AA3: dw::core::DeepIterator::prev() (iterator.cc:708) ==9344== by 0x80D0F91: dw::core::CharIterator::prev() (iterator.cc:825) ==9344== by 0x80CEC72: dw::core::FindtextState::search(char const*, bool, bool) (findtext.cc:104) ==9344== by 0x805AA00: dw::core::Layout::search(char const*, bool, int) (layout.hh:431) ==9344== by 0x805A702: a_UIcmd_findtext_search (uicmd.cc:1484) ==9344== by 0x8090AD6: Findbar::searchBackwards_cb(Fl_Widget*, void*) (findbar.cc:100) ==9344== by 0x411F4FF: Fl_Widget::do_callback(Fl_Widget*, void*) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x805306F: CustButton::handle(int) (tipwin.cc:194) ==9344== by 0x40D99B3: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x40DA255: Fl_Group::handle(int) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== Address 0x363 is not stack'd, malloc'd or (recently) free'd ==9344== ==9344== ==9344== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==9344== Access not within mapped region at address 0x363 ==9344== at 0x80BCFA7: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart(int, int, dw::core::Content*) (oofawarewidget_iterator.cc:102) ==9344== by 0x80BD27D: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev() (oofawarewidget_iterator.cc:204) ==9344== by 0x80D0AA3: dw::core::DeepIterator::prev() (iterator.cc:708) ==9344== by 0x80D0F91: dw::core::CharIterator::prev() (iterator.cc:825) ==9344== by 0x80CEC72: dw::core::FindtextState::search(char const*, bool, bool) (findtext.cc:104) ==9344== by 0x805AA00: dw::core::Layout::search(char const*, bool, int) (layout.hh:431) ==9344== by 0x805A702: a_UIcmd_findtext_search (uicmd.cc:1484) ==9344== by 0x8090AD6: Findbar::searchBackwards_cb(Fl_Widget*, void*) (findbar.cc:100) ==9344== by 0x411F4FF: Fl_Widget::do_callback(Fl_Widget*, void*) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x805306F: CustButton::handle(int) (tipwin.cc:194) ==9344== by 0x40D99B3: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x40DA255: Fl_Group::handle(int) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3)
On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote:
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity.
Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'. i.e. start Dillo with the default home page and search text for 'the'. find the next 'the' a few times, and then use 'previous'. It will work OK until it gets back to the beginning when the next (and final) 'previous' will crash Dillo. Looks like the index is going off the bottom of the search list. I looked at the code a bit, but C++ is all greek to me. Strangely, gdb always reports: Program received signal SIGSEGV, Segmentation fault. 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 102 widget->outOfFlowMgr[sectionIndex - 1]->getWidget (index); this -> sectionIndex=5, index=8 and a backtrace: #0 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 #1 0x080b4822 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev ( this=0x836ec60) at oofawarewidget_iterator.cc:216 #2 0x080c3d5c in dw::core::DeepIterator::prev (this=this at entry=0x83712b0) at iterator.cc:708 #3 0x080c4058 in dw::core::CharIterator::prev (this=0x8360298) at iterator.cc:825 #4 0x080c2877 in dw::core::FindtextState::search (this=0x82c6244, key=key at entry=0x836e9d8 "the", caseSens=false, backwards=backwards at entry=true) at findtext.cc:135 #5 0x08058e43 in search (backwards=1, caseSens=false, str=0x836e9d8 "the", this=<optimized out>) at ../dw/layout.hh:431 #6 a_UIcmd_findtext_search (bw=0x82c5768, key=0x836e9d8 "the", case_sens=0, backward=1) at uicmd.cc:1484 #7 0x08089964 in Findbar::searchBackwards_cb (vfb=0x826d4c8) at findbar.cc:100 #8 0xb7ef2677 in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/lib/libfltk.so.1.3 #9 0xb7e99d13 in Fl_Button::handle(int) () from /usr/lib/libfltk.so.1.3 #10 0xb7e91098 in ?? () from /usr/lib/libfltk.so.1.3 #11 0xb7e92ffd in Fl::handle_(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #12 0xb7e9340c in Fl::handle(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #13 0xb7efa0a8 in fl_handle(_XEvent const&) () from /usr/lib/libfltk.so.1.3 ---Type <return> to continue, or q <return> to quit--- #14 0xb7efb400 in ?? () from /usr/lib/libfltk.so.1.3 #15 0xb7efb5f2 in ?? () from /usr/lib/libfltk.so.1.3 #16 0xb7e929c7 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 #17 0xb7e92ace in Fl::run() () from /usr/lib/libfltk.so.1.3 #18 0x080514e0 in main (argc=1, argv=0xbffff0d4) at dillo.cc:578 Hope that helps. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Hi there! On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote:
On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote:
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity.
Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'.
Yes. I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email? Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review. -- Cheers Jorge.-
Hi Sebastian, On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote:
Hi there!
On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote:
On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote:
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity.
Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'.
Yes.
I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email?
Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review.
OK, the bisect shows the problem starts with commit 4241 which is a new design for textblock iterators. The attached patch works OK for the text search, but I don't know whether it fits with the overall design. It *seems to fit* but I'd prefer you to check it. ;) -- Cheers Jorge.-
On So, Mai 15, 2016, Jorge Arellano Cid wrote:
Hi Sebastian,
On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote:
Hi there!
On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote:
On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote:
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity.
Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'.
Yes.
I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email?
Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review.
OK, the bisect shows the problem starts with commit 4241 which is a new design for textblock iterators.
The attached patch works OK for the text search, but I don't know whether it fits with the overall design.
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try. Sebastian
On 16 May 2016 17:52:11 +0200 "Sebastian Geerken" <sgeerken at dillo.org> wrote:
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try.
Sebastian
Great work Guys, works well :) Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
On Mon, May 16, 2016 at 05:52:11PM +0200, Sebastian Geerken wrote:
On So, Mai 15, 2016, Jorge Arellano Cid wrote:
Hi Sebastian,
On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote:
Hi there!
On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote:
On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote:
Searching the page doesn't cause any more, though.
Searching backward causes segfaults with regularity.
Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'.
Yes.
I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email?
Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review.
OK, the bisect shows the problem starts with commit 4241 which is a new design for textblock iterators.
The attached patch works OK for the text search, but I don't know whether it fits with the overall design.
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try.
Much better! I still wander what a negative sectionIndex means (0 is in flow). It takes negative values sometimes. It should be commented. What should getPart() do upon a negative sectionIndex? HTH. -- Cheers Jorge.-
The attached patch works OK for the text search, but I don't know whether it fits with the overall design.
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try.
Much better!
I still wander what a negative sectionIndex means (0 is in flow). It takes negative values sometimes. It should be commented.
It happens when iterating back gets behind 0. Likewise, it may become larger than NUM_SECTIONS - 1, when iterating forward.
What should getPart() do upon a negative sectionIndex?
It should not be called, actually. This should be checked, first. Sebastian
On Wed, May 18, 2016 at 11:11:17PM +0200, Sebastian Geerken wrote:
The attached patch works OK for the text search, but I don't know whether it fits with the overall design.
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try.
Much better!
I still wander what a negative sectionIndex means (0 is in flow). It takes negative values sometimes. It should be commented.
It happens when iterating back gets behind 0. Likewise, it may become larger than NUM_SECTIONS - 1, when iterating forward.
Yep, it also happens with "index".
What should getPart() do upon a negative sectionIndex?
It should not be called, actually. This should be checked, first.
OK, I've rewrote next() and prev() with full protection and made clear semantics for the corner cases in setValues(). As a side effect, the code got shorter and easier to read. Now in testing phase... -- Cheers Jorge.-
On Thu, May 19, 2016 at 12:02:47PM -0400, Jorge Arellano Cid wrote:
On Wed, May 18, 2016 at 11:11:17PM +0200, Sebastian Geerken wrote:
The attached patch works OK for the text search, but I don't know whether it fits with the overall design.
It *seems to fit* but I'd prefer you to check it. ;)
I've just pushed a variant of your patch, please give it a try.
Much better!
I still wander what a negative sectionIndex means (0 is in flow). It takes negative values sometimes. It should be commented.
It happens when iterating back gets behind 0. Likewise, it may become larger than NUM_SECTIONS - 1, when iterating forward.
Yep, it also happens with "index".
What should getPart() do upon a negative sectionIndex?
It should not be called, actually. This should be checked, first.
OK, I've rewrote next() and prev() with full protection and made clear semantics for the corner cases in setValues().
As a side effect, the code got shorter and easier to read.
Now in testing phase...
Committed. -- Cheers Jorge.-
participants (4)
-
eocene＠gmx.com -
jcid＠dillo.org -
nick＠linicks.net -
sgeerken＠dillo.org