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

page that redraws endlessly

by corvid＠lavabit.com

The following suffices to trigger it for me: <table> <tr> <td> <div> <button></button> </div> <div> words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> <button></button> </div> </td> </table>

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

I wrote: > > http://www.dillo.org/test/redraws.html > > For me, it still breaks with default dillorc options, and also with a > dillo from April 2010. I put up a new version where I trimmed the body down to something comprehensible. The <style> in <head> is still a big mess.

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

http://www.dillo.org/test/redraws.html For me, it still breaks with default dillorc options, and also with a dillo from April 2010.

Sept. 3, 2011

prefs.show_url

by corvid＠lavabit.com

I just found that turning off prefs.show_url messes up the appearance of the UI.

Sept. 3, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Fri, Sep 02, 2011 at 01:48:29PM -0300, Jorge Arellano Cid wrote: > On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > > > [...] > > > > > Any help is appreciatted. > > > > > > > > My guess is that it could be something like > > > > first, one bw asks for a page, and that becomes conn->bw, > > > > and then another bw starts also asking for the page, and > > > > the first bw closes, invalidating the conn->bw, and then > > > > the second bw closes and the cancel expect code tries to > > > > use the old bw. > > > > > > "bw" is a bit a misleading name, bacause each tab is a bw. > > > > > > OTOH, each tab has its own control panel and thus becomes > > > a browser window object. > > > > > > In the case you propose there'd be two different bw. > > > > Right. Why do you feel that they can't be two bws that were > > both closed from the keyboard? > > I have no problems with that. > > What I don't see is two bws with the same memory address being > closed from the keyboard. > > But now I see what you mean: which is a lingering bw in conn, > (which is compatible with my analysis), as there's no need for it > to exist in the UI when the event arrives. > > So we'de have two close events handled OK by two perfectly sane > bws, but one call made on an already defunct bw (i.e. not present > in the UI). > > And you hit it on the nail, because now I can reproduce it!!! Patch committed. FWIW, the testcase I used produced: ==17336== ERROR SUMMARY: 115 errors from 76 contexts (suppressed: 13 from 10) without the patch, and ==17468== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 10) with it. :-) -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > [...] > > > > Any help is appreciatted. > > > > > > My guess is that it could be something like > > > first, one bw asks for a page, and that becomes conn->bw, > > > and then another bw starts also asking for the page, and > > > the first bw closes, invalidating the conn->bw, and then > > > the second bw closes and the cancel expect code tries to > > > use the old bw. > > > > "bw" is a bit a misleading name, bacause each tab is a bw. > > > > OTOH, each tab has its own control panel and thus becomes > > a browser window object. > > > > In the case you propose there'd be two different bw. > > Right. Why do you feel that they can't be two bws that were > both closed from the keyboard? I have no problems with that. What I don't see is two bws with the same memory address being closed from the keyboard. But now I see what you mean: which is a lingering bw in conn, (which is compatible with my analysis), as there's no need for it to exist in the UI when the event arrives. So we'de have two close events handled OK by two perfectly sane bws, but one call made on an already defunct bw (i.e. not present in the UI). And you hit it on the nail, because now I can reproduce it!!! -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > > > Jorge wrote: > > > > > > > > > > [...] > > > > > > > In this one > > > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > > > > > > > [...] > > > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > > > (I don't know valgrind's semantics on it) > > > > > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > > > causes the valgrind message. > > > > > > > > OK, this line gave light in that direction: > > > > > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > > > > > So it's an already freed 'bw' and not its expected URL. > > > > > > > > This starts to make sense... ;-) > > > > > > BTW, why there are two different stack traces? > > > What does the second one mean with respect to the first? > > > > The top one shows the invalid read, and the bottom shows how the > > memory was freed that the top tried to read. > > Thanks. > > Well, in that case we have a weird situation: > > Both stacks have: > > ==28991== by 0x8053F49: CustTabs::handle(int) (uicmd.cc:204) > > Which translates into a bw (window or tab) that's closed twice > by using the keyboard. > > > Strange as it seems, let's analyze it a bit: > For __both_ cases: > > 1.- fltk is sending the SHORTCUT event for KEYS_CLOSE_TAB > 2.- dillo receives it in CustTabs::handle() and gets the bw with: > > UI *ui = (UI*)wizard()->value(); > BrowserWindow *bw = a_UIcmd_get_bw_by_widget(ui); > > (which means the ui is the current one and that the bw is in > our valid bw list.) > > 3.- dillo calls a_UIcmd_close_bw() which: > > a) stops the clients > b) tabs->remove_tab(ui) // This switches to another bw > and removes the ui from wizard > > * Here the question is how can dillo find the ui and same > bw, in the wizard as current, and in the valid bw list > (after 3c), for a second time at 2.- ? > > c) a_Bw_free(bw) // the bw is removed from our valid > list and freed. > > > > The only answer I can find for the above question is: > The memory space for bw is reused with a new ui. This is: > > * create a bw (e.g. address 0x888). > * close the bw, free the bw (0x888 is available again) > * create a bw (malloc reuses address 0x888). > * close the bw // Here we have the situation! > * free the bw (0x888 is available again) > > > which is compatible with: > > "Valgrind Bug254420 - memory pool tracking broken" > http://bugs.kde.org/show_bug.cgi?id=254420 > > > but, of course, I may be wrong... > > > > > > [...] > > > OTOH, analyzing the code: > > > > > > AFAIS: > > > > > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > > > (the only call to a_Bw_free() in the codebase). > > > * bw is valid at [1] > > > * The problematic a_Nav_cancel_expect_if_eq() is called from > > > inside the call chain at [2]. > > > * No other a_UIcmd_close_bw() appears in the log, so how came > > > bw to be invalid then? > > > > > > > > > void a_UIcmd_close_bw(void *vbw) > > > { > > > BrowserWindow *bw = (BrowserWindow *)vbw; > > > UI *ui = BW2UI(bw); > > > CustTabs *tabs = ui->tabs(); > > > 1 Layout *layout = (Layout*)bw->render_layout; > > > > > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > > > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > > > delete(layout); > > > if (tabs) { > > > tabs->remove_tab(ui); > > > if (tabs->num_tabs() == 0) > > > delete tabs->window(); > > > } > > > 3 a_Bw_free(bw); > > > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > > > } > > > > > > > > > Any help is appreciatted. > > > > My guess is that it could be something like > > first, one bw asks for a page, and that becomes conn->bw, > > and then another bw starts also asking for the page, and > > the first bw closes, invalidating the conn->bw, and then > > the second bw closes and the cancel expect code tries to > > use the old bw. > > "bw" is a bit a misleading name, bacause each tab is a bw. > > OTOH, each tab has its own control panel and thus becomes > a browser window object. > > In the case you propose there'd be two different bw. Right. Why do you feel that they can't be two bws that were both closed from the keyboard? > Bottom line: > > This bug is currently holding the dillo-3.0 release. > > Given the analysis, that nobody knows how to reproduce it, > that even if real, it doesn't do much harm, the situation is: > if there's no news in a couple of days, the release will be made. No objections here.

Sept. 2, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > > Jorge wrote: > > > > > > > > [...] > > > > > > In this one > > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > > > > [...] > > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > > (I don't know valgrind's semantics on it) > > > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > > causes the valgrind message. > > > > > > OK, this line gave light in that direction: > > > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > > > So it's an already freed 'bw' and not its expected URL. > > > > > > This starts to make sense... ;-) > > > > BTW, why there are two different stack traces? > > What does the second one mean with respect to the first? > > The top one shows the invalid read, and the bottom shows how the > memory was freed that the top tried to read. Thanks. Well, in that case we have a weird situation: Both stacks have: ==28991== by 0x8053F49: CustTabs::handle(int) (uicmd.cc:204) Which translates into a bw (window or tab) that's closed twice by using the keyboard. Strange as it seems, let's analyze it a bit: For __both_ cases: 1.- fltk is sending the SHORTCUT event for KEYS_CLOSE_TAB 2.- dillo receives it in CustTabs::handle() and gets the bw with: UI *ui = (UI*)wizard()->value(); BrowserWindow *bw = a_UIcmd_get_bw_by_widget(ui); (which means the ui is the current one and that the bw is in our valid bw list.) 3.- dillo calls a_UIcmd_close_bw() which: a) stops the clients b) tabs->remove_tab(ui) // This switches to another bw and removes the ui from wizard * Here the question is how can dillo find the ui and same bw, in the wizard as current, and in the valid bw list (after 3c), for a second time at 2.- ? c) a_Bw_free(bw) // the bw is removed from our valid list and freed. The only answer I can find for the above question is: The memory space for bw is reused with a new ui. This is: * create a bw (e.g. address 0x888). * close the bw, free the bw (0x888 is available again) * create a bw (malloc reuses address 0x888). * close the bw // Here we have the situation! * free the bw (0x888 is available again) which is compatible with: "Valgrind Bug254420 - memory pool tracking broken" http://bugs.kde.org/show_bug.cgi?id=254420 but, of course, I may be wrong... > > [...] > > OTOH, analyzing the code: > > > > AFAIS: > > > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > > (the only call to a_Bw_free() in the codebase). > > * bw is valid at [1] > > * The problematic a_Nav_cancel_expect_if_eq() is called from > > inside the call chain at [2]. > > * No other a_UIcmd_close_bw() appears in the log, so how came > > bw to be invalid then? > > > > > > void a_UIcmd_close_bw(void *vbw) > > { > > BrowserWindow *bw = (BrowserWindow *)vbw; > > UI *ui = BW2UI(bw); > > CustTabs *tabs = ui->tabs(); > > 1 Layout *layout = (Layout*)bw->render_layout; > > > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > > delete(layout); > > if (tabs) { > > tabs->remove_tab(ui); > > if (tabs->num_tabs() == 0) > > delete tabs->window(); > > } > > 3 a_Bw_free(bw); > > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > > } > > > > > > Any help is appreciatted. > > My guess is that it could be something like > first, one bw asks for a page, and that becomes conn->bw, > and then another bw starts also asking for the page, and > the first bw closes, invalidating the conn->bw, and then > the second bw closes and the cancel expect code tries to > use the old bw. "bw" is a bit a misleading name, bacause each tab is a bw. OTOH, each tab has its own control panel and thus becomes a browser window object. In the case you propose there'd be two different bw. >>>>>>>>>>> Bottom line: This bug is currently holding the dillo-3.0 release. Given the analysis, that nobody knows how to reproduce it, that even if real, it doesn't do much harm, the situation is: if there's no news in a couple of days, the release will be made. -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > [...] > > > > > In this one > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > [...] > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > (I don't know valgrind's semantics on it) > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > causes the valgrind message. > > > > OK, this line gave light in that direction: > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > So it's an already freed 'bw' and not its expected URL. > > > > This starts to make sense... ;-) > > BTW, why there are two different stack traces? > What does the second one mean with respect to the first? The top one shows the invalid read, and the bottom shows how the memory was freed that the top tried to read. > If I look the first one (in reading order), it's clear that a > keyboard event closed a browser window cancelling the expect. > This is, for instance, middle-click a link, hit Ctrl-W before the > data stream starts to arrive (while dillo displays the > "contacting host" message). > > In my machine this happens in the expected order with no > problems. Can anybody reproduce the valgrind log using this > procedure? > > OTOH, analyzing the code: > > AFAIS: > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > (the only call to a_Bw_free() in the codebase). > * bw is valid at [1] > * The problematic a_Nav_cancel_expect_if_eq() is called from > inside the call chain at [2]. > * No other a_UIcmd_close_bw() appears in the log, so how came > bw to be invalid then? > > > void a_UIcmd_close_bw(void *vbw) > { > BrowserWindow *bw = (BrowserWindow *)vbw; > UI *ui = BW2UI(bw); > CustTabs *tabs = ui->tabs(); > 1 Layout *layout = (Layout*)bw->render_layout; > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > delete(layout); > if (tabs) { > tabs->remove_tab(ui); > if (tabs->num_tabs() == 0) > delete tabs->window(); > } > 3 a_Bw_free(bw); > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > } > > > Any help is appreciatted. My guess is that it could be something like first, one bw asks for a page, and that becomes conn->bw, and then another bw starts also asking for the page, and the first bw closes, invalidating the conn->bw, and then the second bw closes and the cancel expect code tries to use the old bw. I'm sure it won't turn out to be exactly that, but when I saw that there was a conn->bw, it seemed that there have to be ways for a conn to outlast a bw.

Sept. 1, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 02:58:09PM -0300, Jorge Arellano Cid wrote: > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > [...] > > > > > In this one > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > [...] > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > (I don't know valgrind's semantics on it) > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > causes the valgrind message. > > > > OK, this line gave light in that direction: > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > So it's an already freed 'bw' and not its expected URL. > > > > This starts to make sense... ;-) FYI, looking into the other direction (a false positive), we have this: "Valgrind Bug254420 - memory pool tracking broken" http://bugs.kde.org/show_bug.cgi?id=254420 fixed in 3.6.1. If Jeremy or anybody can find a way to reproduce the log, we'd be very close to nailing the issue down. @Jeremy: what do you get from valgrind using the procedure described in my previous email? TIA. -- Cheers Jorge.-

Sept. 1, 2011