Bug 1240830
| Summary: | [abrt] epiphany-runtime: ephy_certificate_popover_set_address(): epiphany killed by SIGSEGV | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Diogo Campos <diogocamposwd> | ||||||||||||||||||||||||||
| Component: | epiphany | Assignee: | Michael Catanzaro <mcatanzaro> | ||||||||||||||||||||||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||
| Version: | 22 | CC: | debarshir, gecko-bugs-nobody, mcatanzaro, rob.townley | ||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/cdc447b685183abd1f990418f8e619c6b8a6ed1d | ||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:6a9f51730cc1a9426cccc007fdc0232ecfb3aba5 | ||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||
| Last Closed: | 2016-03-01 20:59:31 UTC | Type: | --- | ||||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||
|
Description
Diogo Campos
2015-07-07 21:15:54 UTC
Created attachment 1049572 [details]
File: backtrace
Created attachment 1049573 [details]
File: cgroup
Created attachment 1049574 [details]
File: core_backtrace
Created attachment 1049575 [details]
File: dso_list
Created attachment 1049576 [details]
File: environ
Created attachment 1049577 [details]
File: limits
Created attachment 1049578 [details]
File: maps
Created attachment 1049579 [details]
File: mountinfo
Created attachment 1049580 [details]
File: namespaces
Created attachment 1049581 [details]
File: open_fds
Created attachment 1049582 [details]
File: proc_pid_status
Created attachment 1049583 [details]
File: var_log_messages
Thanks for reporting all these bugs!
Program terminated with signal SIGSEGV, Segmentation fault.
#0 ephy_certificate_popover_set_address (address=0x273e5d0 "", popover=0x30f82c0) at ephy-certificate-popover.c:69
69 uri_text = g_markup_printf_escaped ("<span weight=\"bold\">%s</span>.", uri->host);
Hm, this is a problem with my downstream patchset to display UTF-8 URLs properly. But I am not sure if this code is unsafe, or if the bug is in g_markup_printf_escaped.
I would expect the bug to be reproducible on whatever site you were visiting at the time, which presumably has UTF-8 characters in its hostname?
(In reply to Michael Catanzaro from comment #13) > Thanks for reporting all these bugs! C'mon Michael! I'm just the one who "complains" and writes bad English, you are the one who fixes things! > I would expect the bug to be reproducible on whatever site you were visiting > at the time, which presumably has UTF-8 characters in its hostname? I don't remember which site was, sorry :/ Some idea of a UTF-8 hostname to test this? Or how I can "force" UTF-8 in a hostname? (it *needs* to be in the hostname, btw? Cannot be in another part of the URL? And which characters are considered UTF-8 to this? Everything not in ASCII/English?). As an alternative, I will just keep clicking the thing on every website until it crashes again... (In reply to Diogo Campos from comment #14) > Some idea of a UTF-8 hostname to test this? It seems to be quite hard to find sites with UTF-8 hostnames using internet search engines. :( My recommendation is to look in your browsing history at the sites you viewed yesterday, and look for special characters in the hostname. I just assumed that a UTF-8 hostname is to blame for this; if you don't have any such sites in your browsing history, then I must be wrong. That would be helpful to determine. > Or how I can "force" UTF-8 in a > hostname? (it *needs* to be in the hostname, btw? Cannot be in another part > of the URL? And which characters are considered UTF-8 to this? Everything > not in ASCII/English?). Yeah, if the UTF-8 is in another part of the URL, I don't think it would matter. (I tested on Japanese Wikipedia and it works fine.) Anything that doesn't look like an English character is going to be UTF-8, yes. Tried to reproduce in all (https) websites visited yesterday. No luck. Also, no UTF-8 character spotted in the hostnames. *** Bug 1342608 has been marked as a duplicate of this bug. *** |