April 2011 - Dillo-dev - lists.mailman3.com

No probs - Dillo & Xubuntu 11.04

by dukeofperl＠ml1.net

Hey ... FYI Just got finished an "automatic" upgrade to Xubuntu 11.04! Dillo still works great! So anybody on Ubuntu et al, don't be shy. :) -- Duke

April 28, 2011

1.3 port

by thomas-forum＠orgis.org

Am Wed, 27 Apr 2011 16:07:37 -0300 schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > Hereafter the default for close tab/window is ctrl-w. > > For those that have Ctrl-q hardwired in the brain, just: > > $ echo "<Ctrl>q = close-tab" >> ~/.dillo/keysrc Hey, thanks. I hope other users don't mind the changed default. Now... I guess it's really time to get around and add dillo 1.3 to my distro. I'll have to add fltk 1.3 first, though. Alrighty then, Thomas.

April 28, 2011

Settings Seg-fault

by dukeofperl＠ml1.net

On Wed, 27 Apr 2011, Jorge Arellano Cid wrote: > On Wed, Apr 27, 2011 at 08:35:36PM +0000, corvid wrote: > > I wrote: > > > Rob wrote: > > > > BTW, building the latest 1.3 version with -O0 makes the segfault disappear. > > > > > > Ah! I can reproduce this now with -O2. I'll see what's going on... > > I can also reproduce it with -O2. > > > Does the attached fix it for you? > > > diff -r 165b50e3f996 src/menu.cc > > --- a/src/menu.cc Wed Apr 27 19:56:21 2011 +0000 > > +++ b/src/menu.cc Wed Apr 27 20:34:25 2011 +0000 > > @@ -671,6 +671,7 @@ > > FL_MENU_RADIO|FL_MENU_DIVIDER,0,0,0,0}, > > {"small icons", 0,Menu_panel_change_cb,(void*)10, > > FL_MENU_TOGGLE,0,0,0,0}, > > + {0,0,0,0,0,0,0,0,0}, > > {0,0,0,0,0,0,0,0,0} > > }; > > > > Yes it does! Patch applied! and all is well. Thank you everyone! Niiice browser! -- Duke

April 28, 2011

Settings Seg-fault

by jcid＠dillo.org

On Wed, Apr 27, 2011 at 07:07:29PM -0400, Rob S. wrote: > > [...] > > Did the port used to work on this particular system? > > How about the FLTK2 dillo? > > No - this is a new laptop, and I just recently started > tinkering with Linux on it. ?Prior to that, I was trying to > build Dillo under Cygwin in Windows. ?As for the FLTK2 Dillo, I > don't know, as I have not tried it. ?I think I might give that > a go, and see.? An easy test is to go back before the menu patch was added: $ hg up -r 041d4979092f $ make|grep : and check how it works. This may tell us whether the problem is somewhere in the code thereafter or elsewhere. The fact that corvid and I can reproduce it with -O2 shows there's actually a bug in our code (and corvid's patch fixes it, at least partially, so I recommend testing with the patch). A not so simple but quite interesting check, would be to build it with another gcc version. FWIW, here I have gcc version 4.4.3. A wild shot is to add a few more: {0,0,0,0,0,0,0,0,0}, in src/menu.cc HTH. -- Cheers Jorge.-

April 28, 2011

Settings Seg-fault

by corvid＠lavabit.com

Rob wrote: > > If you go to the Html_tag_close_title stack frame, what do you get for > > p *html > > ? > > (gdb) frame 10#10 0x0000000000422274 in Html_tag_close_title (html=0x7e9600, TagIdx=<value optimized out>) at html.cc:16501650 ? ? ? ? ?a_UIcmd_set_page_title(html->bw, html->Stash->str);(gdb) p *html$1 = {linkReceiver = {<dw::core::Layout::LinkReceiver> = {<lout::signal::Receiver> = {<lout::object::Object> = {_vptr.Object = 0x4b3830}, emitters = 0x7d1510}, <No data fields>},?? ? html = 0x7e9600}, bw = 0x76b0b0, page_url = 0x7eb430, base_url = 0x7d1f80, dw = 0x7e98b0,?? Start_Buf = 0x7c57d0 "<!DOCTYPE HTML>\n<html>\n<head>\n<title>GDB Tutorial | How To Debug With The GNU GDB Debugger</title>\n<meta name=\"description\" content=\"A comprehensive gdb tutorial with examples and exercises\"/>\n<meta "..., Start_Ofs = 0, content_type = 0x7eb250 "text/html", charset = 0x0, stop_parser = false, CurrTagOfs = 90, OldTagOfs = 0, OldTagLine = 1,?? DocType = DT_HTML, DocTypeVersion = 5, cssUrls = 0x7ea780, stack = 0x7d6300, styleEngine = 0x7ea5a0, InFlags = 3, Stash = 0x7d6320, StashSpace = false, pre_column = 0,?? PreFirstChar = false, PrevWasCR = false, PrevWasOpenTag = false, InVisitedLink = false, ReqTagClose = false, TagSoup = true, loadCssFromStash = false, Num_HTML = 1 '\001',?? Num_HEAD = 1 '\001', Num_BODY = 0 '\000', Num_TITLE = 1 '\001', attr_data = 0x7eb020, non_css_link_color = -1, non_css_visited_color = -1, visited_color = -1, forms = 0x7eb040,?? inputs_outside_form = 0x7d96e0, links = 0x7d9700, images = 0x7d1e70, maps = {imageMaps = 0x7d1530, currentMap = 0x0}}(gdb)? Hmm, I was hoping it would look strange inside because the arguments for a_UIcmd_set_page_title(html->bw, html->Stash->str) looked crazy, but it seems that was indeed an effect of the optimization. In a situation like this with optimization on, I would start sticking MSG()s into a_UIcmd_set_page_title() to see the values of variables at different points.

April 28, 2011

Settings Seg-fault

by mr_semantics＠hotmail.com

> That came through as kind of a mess,? Yes - it was not good at all. ?Sorry about that. >but I see that > you have a cleaner copy at > http://cboard.cprogramming.com/tech-board/137344-debugging-problem.html > Glad you found that - I had contemplated just posting a link to that in the first place. > If you go to the Html_tag_close_title stack frame, what do you get for > p *html > ? (gdb) frame 10#10 0x0000000000422274 in Html_tag_close_title (html=0x7e9600, TagIdx=<value optimized out>) at html.cc:16501650 ? ? ? ? ?a_UIcmd_set_page_title(html->bw, html->Stash->str);(gdb) p *html$1 = {linkReceiver = {<dw::core::Layout::LinkReceiver> = {<lout::signal::Receiver> = {<lout::object::Object> = {_vptr.Object = 0x4b3830}, emitters = 0x7d1510}, <No data fields>},?? ? html = 0x7e9600}, bw = 0x76b0b0, page_url = 0x7eb430, base_url = 0x7d1f80, dw = 0x7e98b0,?? Start_Buf = 0x7c57d0 "<!DOCTYPE HTML>\n<html>\n<head>\n<title>GDB Tutorial | How To Debug With The GNU GDB Debugger</title>\n<meta name=\"description\" content=\"A comprehensive gdb tutorial with examples and exercises.\"/>\n<meta "..., Start_Ofs = 0, content_type = 0x7eb250 "text/html", charset = 0x0, stop_parser = false, CurrTagOfs = 90, OldTagOfs = 0, OldTagLine = 1,?? DocType = DT_HTML, DocTypeVersion = 5, cssUrls = 0x7ea780, stack = 0x7d6300, styleEngine = 0x7ea5a0, InFlags = 3, Stash = 0x7d6320, StashSpace = false, pre_column = 0,?? PreFirstChar = false, PrevWasCR = false, PrevWasOpenTag = false, InVisitedLink = false, ReqTagClose = false, TagSoup = true, loadCssFromStash = false, Num_HTML = 1 '\001',?? Num_HEAD = 1 '\001', Num_BODY = 0 '\000', Num_TITLE = 1 '\001', attr_data = 0x7eb020, non_css_link_color = -1, non_css_visited_color = -1, visited_color = -1, forms = 0x7eb040,?? inputs_outside_form = 0x7d96e0, links = 0x7d9700, images = 0x7d1e70, maps = {imageMaps = 0x7d1530, currentMap = 0x0}}(gdb)? Woah! ?Cool! > Did the port used to work on this particular system? > How about the FLTK2 dillo? No - this is a new laptop, and I just recently started tinkering with Linux on it. ?Prior to that, I was trying to build Dillo under Cygwin in Windows. ?As for the FLTK2 Dillo, I don't know, as I have not tried it. ?I think I might give that a go, and see.?

April 28, 2011

Settings Seg-fault

by corvid＠lavabit.com

Rob wrote: > > Does the attached fix it for you? > No, it does not seem to. ?Here is what I am getting - hopefully it is somewhat helpful. ?It consists of: That came through as kind of a mess, but I see that you have a cleaner copy at http://cboard.cprogramming.com/tech-board/137344-debugging-problem.html If you go to the Html_tag_close_title stack frame, what do you get for p *html ? Did the port used to work on this particular system? How about the FLTK2 dillo?

April 28, 2011

Settings Seg-fault

by mr_semantics＠hotmail.com

> @Rob: would you mind double check the patch is correctly > applied on src/menu.cc:674?, then recompile, and also make sure > you run the newly compiled dillo and not the system wide one? I double checked, rebuilt, but unfortunately it is still the same thing. ?:(

April 28, 2011

Settings Seg-fault

by jcid＠dillo.org

On Wed, Apr 27, 2011 at 08:35:36PM +0000, corvid wrote: > I wrote: > > Rob wrote: > > > BTW, building the latest 1.3 version with -O0 makes the segfault disappear. > > > > Ah! I can reproduce this now with -O2. I'll see what's going on... I can also reproduce it with -O2. > Does the attached fix it for you? > diff -r 165b50e3f996 src/menu.cc > --- a/src/menu.cc Wed Apr 27 19:56:21 2011 +0000 > +++ b/src/menu.cc Wed Apr 27 20:34:25 2011 +0000 > @@ -671,6 +671,7 @@ > FL_MENU_RADIO|FL_MENU_DIVIDER,0,0,0,0}, > {"small icons", 0,Menu_panel_change_cb,(void*)10, > FL_MENU_TOGGLE,0,0,0,0}, > + {0,0,0,0,0,0,0,0,0}, > {0,0,0,0,0,0,0,0,0} > }; > Yes it does! And I also checked that regressing the repo to the version before the submenu patch (e816e06ee901) also "fixes" it. @Rob: would you mind double check the patch is correctly applied on src/menu.cc:674?, then recompile, and also make sure you run the newly compiled dillo and not the system wide one? -- Cheers Jorge.-

April 28, 2011

Settings Seg-fault

by dukeofperl＠ml1.net

On Wed, 27 Apr 2011, Jorge Arellano Cid wrote: > On Wed, Apr 27, 2011 at 02:26:01PM -0600, Duke Normandin wrote: > > On Wed, 27 Apr 2011, Rob S. wrote: > > [snip the headache] :) > > > > > ..... BTW, building the latest 1.3 version with -O0 > > > makes the segfault disappear. > > > > I glad to see that I'm not the only one having the problem. I wish > > that I was a C / C++ programmer - than I could help out. BTW, -O0 is an > > argument to what? > > To the compiler (gcc). It's an optimization level. > If this is the case, it could be a bug in the compiler. Thanks! -- Duke

April 27, 2011