After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581080 - crash in Gnote: Importing favicon (conve...
crash in Gnote: Importing favicon (conve...
Status: RESOLVED FIXED
Product: gnote
Classification: Applications
Component: main
0.3.x
Other All
: High critical
: 1.0
Assigned To: gnote-maint
gnote-maint
Depends on:
Blocks:
 
 
Reported: 2009-05-02 08:08 UTC by Matěj Cepl
Modified: 2009-05-14 18:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
proposed fix (1.67 KB, patch)
2009-05-03 03:41 UTC, Yves Junqueira
needs-work Details | Review
sanitize_hostname; catch a parent exception instead (1.93 KB, patch)
2009-05-04 01:01 UTC, Yves Junqueira
none Details | Review

Description Matěj Cepl 2009-05-02 08:08:19 UTC
Version: 0.1.0

What were you doing when the application crashed?
Importing favicon (converted to PNG format) for https://bugzilla.redhat.com (originally from https://bugzilla.redhat.com/images/favicon.ico).


Distribution: Fedora release 10.93 (Leonidas)
Gnome Release: 2.26.1 2009-04-29 (Red Hat, Inc)
BugBuddy Version: 2.26.0

System: Linux 2.6.29.1-102.fc11.x86_64 #1 SMP Mon Apr 20 15:33:38 EDT 2009 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10601000
Selinux: Permissive
Accessibility: Disabled
GTK+ Theme: Nodoka
Icon Theme: Fedora
GTK+ Modules: canberra-gtk-module, gnomebreakpad

Memory status: size: 724066304 vsize: 724066304 resident: 98639872 share: 21704704 rss: 98639872 rss_rlim: 18446744073709551615
CPU usage: start_time: 1241251273 rtime: 468 utime: 398 stime: 70 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/gnote'

[?1034h[Thread debugging using libthread_db enabled]
[New Thread 0x7f9964433910 (LWP 15622)]
0x00007f996d85ad4d in __libc_waitpid (pid=15623, 
    stat_loc=<value optimized out>, options=0)
    at ../sysdeps/unix/sysv/linux/waitpid.c:41
41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
Current language:  auto; currently minimal

Thread 1 (Thread 0x7f996ef54800 (LWP 15458))

  • #0 __libc_waitpid
    at ../sysdeps/unix/sysv/linux/waitpid.c line 41
  • #1 g_spawn_sync
    from /lib64/libglib-2.0.so.0
  • #2 g_spawn_command_line_sync
    from /lib64/libglib-2.0.so.0
  • #3 ??
    from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
  • #4 <signal handler called>
  • #5 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #6 *__GI_abort
    at abort.c line 88
  • #7 g_logv
    from /lib64/libglib-2.0.so.0
  • #8 g_log
    from /lib64/libglib-2.0.so.0
  • #9 Glib::exception_handlers_invoke()
    from /usr/lib64/libglibmm-2.4.so.1
  • #10 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*)
    from /usr/lib64/libglibmm-2.4.so.1
  • #11 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #12 ??
    from /lib64/libgobject-2.0.so.0
  • #13 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #14 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #15 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #16 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #17 ??
    from /lib64/libgobject-2.0.so.0
  • #18 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #19 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #20 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #21 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #22 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #23 ??
    from /lib64/libgobject-2.0.so.0
  • #24 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #25 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #26 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #27 gtk_propagate_event
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #28 gtk_main_do_event
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #29 ??
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #30 g_main_context_dispatch
    from /lib64/libglib-2.0.so.0
  • #31 ??
    from /lib64/libglib-2.0.so.0
  • #32 g_main_loop_run
    from /lib64/libglib-2.0.so.0
  • #33 gtk_main
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #34 gnote::Gnote::start_tray_icon
    at gnote.cpp line 181
  • #35 gnote::Gnote::main
    at gnote.cpp line 135
  • #36 main
    at main.cpp line 39


---- Critical and fatal warnings logged during execution ----

** glibmm **: 
unhandled exception (type std::exception) in signal handler:
what: boost::filesystem::copy_file: Adresář nebo soubor neexistuje: "/home/matej/redhat/brc.png", "/home/matej/.gnote/BugzillaIcons/https://bugzilla.redhat.com.png"
Comment 1 Matěj Cepl 2009-05-02 08:14:04 UTC
Might be caused by entering https://bugzilla.redhat.com as domain of the bugzilla.
When entered merely bugzilla.redhat.com import was succesful, but still link in a note doesn't have a red hat.
Comment 2 Matěj Cepl 2009-05-02 08:15:20 UTC
This happened when entered

https://bugzilla.redhat.com

as the bugzilla domain. When entered merely

bugzilla.redhat.com

no crash happened, but still there is no red hat logo in a note.
Comment 3 Yves Junqueira 2009-05-03 03:41:43 UTC
Created attachment 133836 [details] [review]
proposed fix

this crash happens because the user tried to save a file named "https://" and the slash is an invalid filename, naturally.

I'm a newbie C++ coder, so prepare for utter ugliness :-).
Comment 4 Hubert Figuiere (:hub) 2009-05-03 07:07:44 UTC
Catching the exception is actually a good idea. Changing the message is not needed.

The problem is that it expect a hostname and not a URL. That issue should be addressed as well by parsing the URL.
Comment 5 Yves Junqueira 2009-05-04 01:01:59 UTC
Created attachment 133892 [details] [review]
sanitize_hostname; catch a parent exception instead

Hi, this is my second attempt. Hopefully I'm getting closer to the final solution:

- It sanitizes the hostname, kind of, and tries to remove http(s):// if it's there. Although this probably solves most cases, it's not a real URL string parsing. Unfortunately I could not find a Glib/Boost method that actually splits an URI, so I went with a partial solution. Let me know what are your thoughts.

- Instead of catching sharp::Exception *and* std::exception, as in my previous patch, I realized that just catching std::exception is enough, because shard::Exception inherits from it.
Comment 6 Hubert Figuiere (:hub) 2009-05-04 06:49:09 UTC
actually I'd prefer that sharp::Uri be used. This need to have sharp::Uri::get_host() to be implemented (mistakenly forgotten) and possibly add a sharp::Uri::get_scheme()
Comment 7 Hubert Figuiere (:hub) 2009-05-14 18:40:29 UTC
committed a fix for that inspired on ideas for this patch.


Thanks for your report.