| Summary: | elinks crashes on URI redirection | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Amit Shah <amit.shah> | ||||||
| Component: | elinks | Assignee: | Kamil Dudka <kdudka> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 16 | CC: | kdudka, ovasik | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | abrt_hash:d86302bf0393bb978e2b574961175f98cb98e3a0 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-04-11 13:49:08 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Amit Shah
2012-02-14 06:55:06 UTC
Created attachment 561773 [details]
File: maps
Created attachment 561774 [details]
File: backtrace
Comment on attachment 561774 [details] File: backtrace >#5 0x000000000047f295 in compare_uri (a=0x9a9a9a9a9a9a9a9a, b=0x272f320, components=<optimized out>) at uri.c:470 compare_uri() seems to be called with an invalid pointer. 0x9a9a9a9a9a9a9a9a looks like a poisoning constant. >#6 0x00000000004a3b17 in do_redirect (cached=0x277f4d0, download_p=<synthetic pointer>, ses=0x272f3d0) at task.c:414 cached->uri must hold the value 0x9a9a9a9a9a9a9a9a at this level. >#7 do_move (download_p=<synthetic pointer>, ses=0x272f3d0) at task.c:482 (*download_p)->cached->uri must hold the value 0x9a9a9a9a9a9a9a9a at this level. So far I have no idea why the above is happening. Could you please provide more details on how to reproduce the issue? I was using mobile broadband when this happened: so the signal comes and goes. This happened once when the signal was bad, no network activity could happen, but NM had kept the connection ON. Just a few moments after this crash, NM marked the connection as dropped, so I'm guessing it was already dropped for a while, and elinks barfed on that? Did you use a proxy? Nope, no proxy. Really no idea where the value 0x9a9a9a9a9a9a9a9a originates from. There must have been some uncaught memory corruption. The explicit poisoning constants are: #define _MAGIC 0x950412de #define _MAGIC_SWAPPED 0xde120495 #define LISTMAGIC1 ((void *) 0xdadababa) #define LISTMAGIC2 ((void *) 0xd0d0b0b0) #define LISTMAGIC3 ((void *) 0x25254545) #define AH_SANITY_MAGIC 0xD3BA110C #define AH_FREE_MAGIC 0xD3BF110C #define HASH_MAGIC 0xdeadbeef #define STRING_MAGIC 0x2E5BF271 ... but most of them seem to be used only in debug build anyway. Unless we get a reliable reproducer, it is unlikely to move this bug forward. I have this in my env: export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) which is a great way to catch malloc-related bugs. Hope that helps a bit :) (In reply to comment #8) > I have this in my env: > > export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) > > which is a great way to catch malloc-related bugs. Hope that helps a bit :) Thanks. This means elinks likely operates on already freed data, maybe a cache entry has been invalidated meanwhile. Unfortunately, I do not know the elinks internal data structures enough to consider all possibilities. This bug could be hardly investigated by reading the backtrace only. Please reopen the bug if you find a reliable way to trigger the crash. |