[Dillo-dev] Dillo_grows merged

3 views
Skip to first unread message

Sebastian Geerken

unread,
Apr 18, 2016, 12:18:38 PM4/18/16
to dill...@dillo.org
Hi!

The dillo_grows repository has just been merged into the main
repository at <http://hg.dillo.org/dillo>.

Hopefully, this will mean that all these changes will soon make it
into a new release.

Sebastian

signature.asc

Nick Warne

unread,
Apr 18, 2016, 12:48:13 PM4/18/16
to dill...@dillo.org
Hi Seb,
I hope not! There are still a lot of issues compared with 3.0.5.

Google doesn't render right:

https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo

The forums previously mentioned still get stuck at the front with no
scrolling available:

http://forums.thinkbroadband.com

The horizontal line issue is still with us:

https://linicks.net/AnAdIc/

And perhaps worst of all, here the 'advert place holder' at the top of
the page gets allocated, but obviously with no ads:

http://www.boards2go.com/boards/board.cgi?user=dharrison

I guess there are going to be many permutations of the above issues - at
least 3.0.5 renders these pages as 'acceptable'.

Regards,

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"

_______________________________________________
Dillo-dev mailing list
Dill...@dillo.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

August Karlstrom

unread,
Apr 18, 2016, 2:14:50 PM4/18/16
to dill...@dillo.org
On 2016-04-18 18:45, Nick Warne wrote:
> Google doesn't render right:
>
> https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo

Neither does Google Translate:

https://translate.google.com/

With and without CSS the form doesn't behave correctly.


-- August

Johannes Hofmann

unread,
Apr 18, 2016, 2:49:39 PM4/18/16
to dill...@dillo.org
On Mon, Apr 18, 2016 at 05:45:54PM +0100, Nick Warne wrote:
> Hi Seb,
>
> On 18/04/16 17:16, Sebastian Geerken wrote:
> > Hi!
> >
> > The dillo_grows repository has just been merged into the main
> > repository at <http://hg.dillo.org/dillo>.
> >
> > Hopefully, this will mean that all these changes will soon make it
> > into a new release.
>
> I hope not! There are still a lot of issues compared with 3.0.5.
>
> Google doesn't render right:
>
> https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo
>
> The forums previously mentioned still get stuck at the front with no
> scrolling available:
>
> http://forums.thinkbroadband.com
>
> The horizontal line issue is still with us:
>
> https://linicks.net/AnAdIc/
>
> And perhaps worst of all, here the 'advert place holder' at the top of
> the page gets allocated, but obviously with no ads:
>
> http://www.boards2go.com/boards/board.cgi?user=dharrison
>
> I guess there are going to be many permutations of the above issues - at
> least 3.0.5 renders these pages as 'acceptable'.

It would be great if everyone would help tracking down the remaining issues
by providing minimal examples that reproduce the problem.

Cheers,
Johannes

Sebastian Geerken

unread,
Apr 18, 2016, 3:18:47 PM4/18/16
to dill...@dillo.org
On Mo, Apr 18, 2016, August Karlstrom wrote:
> On 2016-04-18 18:45, Nick Warne wrote:
> >Google doesn't render right:
> >
> >https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo
>
> Neither does Google Translate:
>
> https://translate.google.com/
>
> With and without CSS the form doesn't behave correctly.

This is interresting. Probably because of the HTML5 changes, the
textarea was assigned a height of 2 rows. Both dillo 3.0.5 and dillo
3.1-dev cannot handle textarea with only 2 rows, but dillo 3.0.5 uses
10 as default, while 3.1-dev uses 2, at least in this case.

I've increased the value to 3, so that translate.google.com is now
usable.

Sebastian

signature.asc

higuita

unread,
Apr 18, 2016, 3:37:31 PM4/18/16
to Nick Warne, dill...@dillo.org
On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <ni...@linicks.net> wrote:
> The forums previously mentioned still get stuck at the front with no
> scrolling available:
>
> http://forums.thinkbroadband.com

This one, if we disable embedded CSS, it will revert back to the
old style

Higuita
--
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger. It works the same in every country.
-- Hermann Goering, Nazi and war criminal, 1883-1946

Johannes Hofmann

unread,
Apr 18, 2016, 4:03:47 PM4/18/16
to dill...@dillo.org
the Google issue can be reproduced with

<div>
<div style="float:left;display:inline-block">dillo</div>
<div style="float:left;display:inline-block">dillo</div>
<div style="float:left;display:inline-block">dillo</div>
</div>

which did render one block next to the other in dillo 3.0.5 and
now renders each block below each other.

Sebastian Geerken

unread,
Apr 18, 2016, 4:11:51 PM4/18/16
to dill...@dillo.org
On Mon, Apr 18, 2016, higuita wrote:
> On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <ni...@linicks.net> wrote:
> > The forums previously mentioned still get stuck at the front with no
> > scrolling available:
> >
> > http://forums.thinkbroadband.com
>
> This one, if we disable embedded CSS, it will revert back to the
> old style

If you put the line

div, table { height: auto !important }

into ~/.dillo/style.css, then both <http://forums.thinkbroadband.com>
and <https://linicks.net/AnAdIc/> will be rendered as by dillo 3.0.5.

This is not a solution, of course, but shows the root of the problem.
Actually, it may be an option to turn of CSS `height` for some
elements (for which dillo 3.0.5 does not support `height`) and work on
this issue for the release after 3.1.

Sebastian

signature.asc

Sebastian Geerken

unread,
Apr 18, 2016, 4:18:38 PM4/18/16
to dill...@dillo.org
On Mo, Apr 18, 2016, Johannes Hofmann wrote:
> the Google issue can be reproduced with
>
> <div>
> <div style="float:left;display:inline-block">dillo</div>
> <div style="float:left;display:inline-block">dillo</div>
> <div style="float:left;display:inline-block">dillo</div>
> </div>
>
> which did render one block next to the other in dillo 3.0.5 and
> now renders each block below each other.

Yes, floats are always positioned one below the other, never side by
side, as most other browsers do. I've plans to implement the latter,
but is is nothing to be done for the short term.

It is interesting that dillo 3.0.5 shows them side by side (actually
like an inline element), although `display:inline-block` is not
supported before 3.1. Is there some workaround?

Sebastian

signature.asc

eocene

unread,
Apr 18, 2016, 9:01:51 PM4/18/16
to dill...@dillo.org

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
#2 0x080bcc0e in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::OOFAwareWidgetIterator (this=0x9e446a8, widget=0x9484458, mask=108, atEnd=true,
numContentsInFlow=0) at oofawarewidget_iterator.cc:46
#3 0x080b40a3 in dw::Textblock::TextblockIterator::TextblockIterator (
this=0x9e446a8, textblock=0x9484458, mask=108, atEnd=true)
at textblock_iterator.cc:36
#4 0x080ad18a in dw::Textblock::iterator (this=0x9484458, mask=108,
atEnd=true) at textblock.cc:1172
#5 0x080d092f in dw::core::DeepIterator::prev (this=0x923c848)
at iterator.cc:711
#6 0x080d099f in dw::core::DeepIterator::prev (this=0x923c848)
at iterator.cc:723
#7 0x080d0dc6 in dw::core::CharIterator::prev (this=0x9e446d8)
at iterator.cc:825
#8 0x080cf0ab in dw::core::FindtextState::search0 (this=0x91554fc,
backwards=true, firstTrial=false) at findtext.cc:273
#9 0x080ceaf8 in dw::core::FindtextState::search (this=0x91554fc,
key=0x94e9dd0 "rows ", caseSens=false, backwards=true) at findtext.cc:113
#10 0x0805aa01 in dw::core::Layout::search (this=0x9155430,
str=0x94e9dd0 "rows ", caseSens=false, backwards=1) at ../dw/layout.hh:431
#11 0x0805a703 in a_UIcmd_findtext_search (bw=0x91550a0,
key=0x94e9dd0 "rows ", case_sens=0, backward=1) at uicmd.cc:1484
#12 0x08090973 in Findbar::searchBackwards_cb (vfb=0x914afa8) at findbar.cc:100
#13 0xb75e8500 in Fl_Widget::do_callback(Fl_Widget*, void*) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#14 0xb7592d33 in Fl_Button::handle(int) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#15 0x08052f03 in TipWinButton::handle (this=0x9154dd8, e=12) at tipwin.cc:158
#16 0x08053070 in CustButton::handle (this=0x9154dd8, e=12) at tipwin.cc:194
#17 0xb75a29b4 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#18 0xb75a3256 in Fl_Group::handle(int) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#19 0x08090eae in Findbar::handle (this=0x914afa8, event=12) at findbar.cc:192
#20 0xb75a29b4 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#21 0xb75a3256 in Fl_Group::handle(int) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#22 0x08055b2d in UI::handle (this=0x914d698, event=12) at ui.cc:790
#23 0xb758a62b in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#24 0xb758b732 in Fl::handle_(int, Fl_Window*) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#25 0xb758b9bc in Fl::handle(int, Fl_Window*) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#26 0xb758b75f in Fl::handle_(int, Fl_Window*) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#27 0xb758b9bc in Fl::handle(int, Fl_Window*) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#28 0xb75edd40 in fl_handle(_XEvent const&) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#29 0xb75ef486 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#30 0xb75ef6b6 in fl_wait(double) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#31 0xb758c567 in Fl::wait(double) ()
from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#32 0xb758c6de in Fl::run() () from /usr/lib/i386-linux-gnu/libfltk.so.1.3
#33 0x08052443 in main (argc=1, argv=0xbff0d434) at dillo.cc:578

Johannes Hofmann

unread,
Apr 19, 2016, 2:29:03 AM4/19/16
to dill...@dillo.org
inline-block was treated as inline in dillo 3.0.5 which happens to
look "ok" for the google case.

Nick Warne

unread,
Apr 19, 2016, 12:27:31 PM4/19/16
to dill...@dillo.org
OK, great. The other solution for the broadband forums is even better -
so good stuff.

Thanks!

Nick Warne

unread,
Apr 19, 2016, 12:28:37 PM4/19/16
to dill...@dillo.org


On 18/04/16 20:34, higuita wrote:
> On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <ni...@linicks.net> wrote:
>> The forums previously mentioned still get stuck at the front with no
>> scrolling available:
>>
>> http://forums.thinkbroadband.com
>
> This one, if we disable embedded CSS, it will revert back to the
> old style

Thanks!

I am a fool for not thinking to try that.

OK, dillo-dev can be used and tested by me at least :)

Nick Warne

unread,
Apr 19, 2016, 12:30:23 PM4/19/16
to dill...@dillo.org


On 18/04/16 17:16, Sebastian Geerken wrote:
OK, with a few of the *fixes* in place, I can't believe that Dillo could
get any faster ~ but it does!

Great job, thank you!

Jorge Arellano Cid

unread,
Apr 23, 2016, 11:05:29 AM4/23/16
to dill...@dillo.org
My testing went great so far, so +1.

Again, I'm very pleased to have dillo's speed back! 8-)

--
Cheers
Jorge.-

eocene

unread,
Apr 24, 2016, 6:04:10 PM4/24/16
to dill...@dillo.org
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.

eocene

unread,
May 15, 2016, 3:00:04 AM5/15/16
to dill...@dillo.org
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)

Nick Warne

unread,
May 15, 2016, 8:19:52 AM5/15/16
to dill...@dillo.org
On Sat, 14 May 2016 22:48:12 +0000
eocene <eoc...@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@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@entry=0x836e9d8 "the", caseSens=false,
backwards=backwards@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"

Jorge Arellano Cid

unread,
May 15, 2016, 4:45:58 PM5/15/16
to dill...@dillo.org
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 <eoc...@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.-

Jorge Arellano Cid

unread,
May 15, 2016, 8:44:22 PM5/15/16
to dill...@dillo.org
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 <eoc...@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.-
it.diff

Sebastian Geerken

unread,
May 16, 2016, 11:54:28 AM5/16/16
to dill...@dillo.org
I've just pushed a variant of your patch, please give it a try.

Sebastian

signature.asc

Nick Warne

unread,
May 16, 2016, 12:25:36 PM5/16/16
to dill...@dillo.org
On 16 May 2016 17:52:11 +0200
"Sebastian Geerken" <sgee...@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"

Jorge Arellano Cid

unread,
May 17, 2016, 9:57:35 PM5/17/16
to dill...@dillo.org
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.

Sebastian Geerken

unread,
May 18, 2016, 5:13:09 PM5/18/16
to dill...@dillo.org
> > > 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

signature.asc

Jorge Arellano Cid

unread,
May 19, 2016, 12:06:49 PM5/19/16
to dill...@dillo.org
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...

Jorge Arellano Cid

unread,
May 19, 2016, 2:25:58 PM5/19/16
to dill...@dillo.org
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.
Reply all
Reply to author
Forward
0 new messages