أحمد المحمودي [EMAIL PROTECTED] writes:
I refresh the page http://launchpad.net/~aelmahmoudy/+archive, and while
the page is refreshing I open a link
(https://launchpad.net/~aelmahmoudy/+archive/+build/669073) in another
tab, then refresh this tab (in which the new links was opened), and then
close the tab to return to the previous tab (which contained
http://launchpad.net/~aelmahmoudy/+archive). At that point, when I
closed the tab contained the newly opened link after refresh, the crash
occurs.
Thank you for these clear instructions with which I could easily
reproduce the bug. Valgrind showed the following:
==28016== Invalid read of size 4
==28016==at 0x8112C54: debug_mem_free (memdebug.c:440)
==28016==by 0x81313FF: destroy_vs (vs.c:54)
==28016==by 0x80FD41F: destroy_location (location.c:51)
==28016==by 0x80FC9B6: free_history (history.c:34)
==28016==by 0x80FC90B: destroy_history (history.c:51)
==28016==by 0x81004EF: destroy_session (session.c:1166)
==28016==by 0x8100993: tabwin_func (session.c:1260)
==28016==by 0x810CB42: delete_window (window.c:85)
==28016==by 0x810AF8B: really_close_tab (tab.c:185)
==28016==by 0x810AFF9: close_tab (tab.c:200)
==28016==by 0x8117306: do_action (action.c:539)
==28016==by 0x81307AA: send_kbd_event (view.c:1468)
==28016== Address 0x489CED8 is 16 bytes inside a block of size 161 free'd
==28016==at 0x402210F: free (vg_replace_malloc.c:233)
==28016==by 0x8112DEC: debug_mem_free (memdebug.c:484)
==28016==by 0x81313FF: destroy_vs (vs.c:54)
==28016==by 0x80FD41F: destroy_location (location.c:51)
==28016==by 0x80FC9B6: free_history (history.c:34)
==28016==by 0x80FC90B: destroy_history (history.c:51)
==28016==by 0x81004EF: destroy_session (session.c:1166)
==28016==by 0x8100993: tabwin_func (session.c:1260)
==28016==by 0x810CB42: delete_window (window.c:85)
==28016==by 0x810AF8B: really_close_tab (tab.c:185)
==28016==by 0x810AFF9: close_tab (tab.c:200)
==28016==by 0x8117306: do_action (action.c:539)
i.e., the memory block was freed twice in exactly the same way.
I then looked for places where view_state.form_info was set, and
sure enough, copy_vs could copy the pointer from another struct
view_state and then leave it unchanged. I think this could not
happen in releases earlier than 0.12pre1, because there was no
way for view_state.form_info_len to become 0 while
view_state.form_info was not NULL.
Please try the patch below. Would you like Reported by أحمد
المحمودي or something like that in the commit message? (I am
wary of adding such things without explicit permission, because
of the privacy laws around here.)
--
Fix crash after a tab was opened during reload.
---
commit b07fecc2be6eeb7e20e555f6128e50f1ed4ee7f9
tree 5df3f87ddb3ed9bae1126009cd755f7137c89cf6
parent 6b05cdb3a0a12e8cf8bae3860b1a59e86d3076a1
author Kalle Olavi Niemitalo [EMAIL PROTECTED] Tue, 15 Jul 2008 00:09:27 +0300
committer Kalle Olavi Niemitalo [EMAIL PROTECTED] Tue, 15 Jul 2008 00:09:27
+0300
NEWS |2 ++
src/viewer/text/vs.c |6 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index b01a90a..7108a8e 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,8 @@ generally also includes the bug fixes made in ELinks
0.11.4.GIT.
Bugs that should be removed from NEWS before the 0.12.0 release:
+* critical: Fix crash after a tab was opened during reload. This was
+ triggered by the bug 620 fix in ELinks 0.12pre1.
* major bug 1026 in user SMJS: Protect the callback of elinks.load_uri
from the garbage collector. The elinks.load_uri method was added in
ELinks 0.12pre1.
diff --git a/src/viewer/text/vs.c b/src/viewer/text/vs.c
index d0bbdf5..a7978db 100644
--- a/src/viewer/text/vs.c
+++ b/src/viewer/text/vs.c
@@ -79,6 +79,12 @@ copy_vs(struct view_state *dst, struct view_state *src)
dst-ecmascript_fragile = 1;
#endif
+ /* destroy_vs(vs) does mem_free_if(vs-form_info), so each
+* view_state must have its own form_info. Normally we make a
+* copy below, but not if src-form_info_len is 0, which it
+* can be even if src-form_info is not NULL. */
+ dst-form_info = NULL;
+
/* Clean as a baby. */
dst-doc_view = NULL;
pgpPDwky7eNRg.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
