Description of problem: edited. removed personal info. Version-Release number of selected component: lynx-2.8.8-0.3.dev16.fc20 Additional info: reporter: libreport-2.2.2 backtrace_rating: 4 cmdline: lynx http://www.kickassunblock.info/ crash_function: FatalProblem executable: /usr/bin/lynx kernel: 3.13.10-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 500 Truncated backtrace: Thread no. 1 (9 frames) #2 FatalProblem at LYMain.c:4520 #4 scan_cookie_sublist at LYCookie.c:726 #5 LYAddCookieHeader at LYCookie.c:1886 #6 HTLoadHTTP at ../../../WWW/Library/Implementation/HTTP.c:1350 #7 HTLoad at ../../../WWW/Library/Implementation/HTAccess.c:706 #8 HTLoadDocument at ../../../WWW/Library/Implementation/HTAccess.c:939 #9 HTLoadAbsolute at ../../../WWW/Library/Implementation/HTAccess.c:1121 #10 getfile at LYGetFile.c:806 #11 mainloop at LYMainLoop.c:5853
Created attachment 918910 [details] File: backtrace
Created attachment 918911 [details] File: cgroup
Created attachment 918912 [details] File: core_backtrace
Created attachment 918914 [details] File: dso_list
Created attachment 918916 [details] File: environ
Created attachment 918919 [details] File: limits
Created attachment 918921 [details] File: maps
Created attachment 918923 [details] File: open_fds
Created attachment 918925 [details] File: proc_pid_status
Created attachment 918927 [details] File: var_log_messages
hl = 0x9d9d9d9d9d9d9d9d looks like an apparent use after free bug due to the setting MALLOC_PERTURB_=157 in your environment. Is this something I can reproduce locally?
I suspect this is caused by a call to HTList_removeObject(de->cookie_list, ...), which can invalidate de->cookie_list without updating the reference in case the object to remove is found at position zero. I will tell the maintainer...
Actually, my analysis appears to be wrong. The first item of the list should be a header that contains no object (and is never freed by HTList_removeObject()). So the memory pointed by de->cookie_list must be freed somewhere else...
I don't see a crash in visiting that site. However, using valgrind, I see this (which is fixed in 2.8.8pre.5): ==15557== at 0x525C709: idna_to_ascii_4z (in /usr/lib64/libidn.so.11.6.11) ==15557== by 0x525C9A7: idna_to_ascii_8z (in /usr/lib64/libidn.so.11.6.11) ==15557== by 0x497267: HTParse (in /usr/local/bin/lynx) ==15557== by 0x448033: LYEnsureAbsoluteURL (in /usr/local/bin/lynx) ==15557== by 0x42C10D: main (in /usr/local/bin/lynx) ==15557== Address 0x7e57aa4 is 4 bytes inside a block of size 5 alloc'd ==15557== at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-am> ==15557== by 0x525C863: idna_to_ascii_4z (in /usr/lib64/libidn.so.11.6.11) ==15557== by 0x525C9A7: idna_to_ascii_8z (in /usr/lib64/libidn.so.11.6.11) ==15557== by 0x497267: HTParse (in /usr/local/bin/lynx) ==15557== by 0x448033: LYEnsureAbsoluteURL (in /usr/local/bin/lynx) ==15557== by 0x42C10D: main (in /usr/local/bin/lynx) 2014-02-14 (2.8.8pre.5) * use idn_free() rather than ordinary free (patch by GV)
hmm - sorry (was running a test-version of lynx, not your package). With your package, valgrind has nothing to report.
(In reply to Thomas E. Dickey from comment #14) > I don't see a crash in visiting that site. I was not able to reproduce the crash either. > However, using valgrind, > I see this (which is fixed in 2.8.8pre.5): It looks like the first line of valgrind's output is missing. What was the actual error reported by valgrind? Was it an invalid read? If so, it looks very similar to bug #678518 comment #2 -- in that case, it was a false positive of valgrind caused by the string routines optimization that GCC uses with -O2.
yes, it looks like that case (thanks)
(In reply to Kamil Dudka from comment #11) > hl = 0x9d9d9d9d9d9d9d9d looks like an apparent use after free bug due to the > setting MALLOC_PERTURB_=157 in your environment. Is this something I can > reproduce locally? That's likely correct. While the initial command line was correct, if I remember correctly, it crashed after a a bit navigating on and off, so the command line argument might not be relevant. Argh, greetings, Thomas E. Dickey. We have corresponded some years ago about cxterm (the xterm with an extra cjk-input panel and does anticipative/phrasal inputs...).
I didn't notice MALLOC_PERTURB as a factor before. But setting that doesn't seem to change anything (I have not been able to find a case which shows any breakage). By the way, the original test-URL is defunct...
I am closing the bug due to lack of information. Feel free to reopen it once you find reliable steps to reproduce.
I think this could be the same bug I fixed yesterday which has annoyed me quite a bit for a while, since we on MirBSD have a malloc that overwrites free(3)d space. http://thread.gmane.org/gmane.comp.web.lynx.devel/8441/focus=8442 Please try whether the patch from there helps for you.
Hm, actually, looking at it, LYHandleCookies() seems to have the same bug. I think all 23 calls to HTList_removeObject need to be audited.
Sorry that was a one off event and I had not been able to reliably reproduce this anyway.