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 740396 - Remove uses of g_error in ephy-history-service and ephy-sqlite-connection
Remove uses of g_error in ephy-history-service and ephy-sqlite-connection
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: History
3.14.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 738308 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-11-20 02:18 UTC by Michael Catanzaro
Modified: 2014-12-10 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Don't crash when a database access fails (27.58 KB, patch)
2014-12-09 18:49 UTC, Michael Catanzaro 		committed Details | Review

Description Michael Catanzaro 2014-11-20 02:18:34 UTC 
Currently, whenever a database operation fails (in e.g. ephy-history-service.c, ephy-history-service-urls-table.c, and ephy-sqlite-connection.c, maybe other files too) we call g_error() to report a fatal error, crashing epiphany and triggering distro bug reporting tools.  This is bad because there are all sort of non-fatal reasons why a database access could fail. For example, if you delete ~/.config/epiphany/ephy-history.db while epiphany is open, epiphany will crash.

There are also several places in these files where there is code after a call to g_error() (usually g_error_free() and then a return with a failure status), which doesn't make sense because g_error() will never return.
Comment 1 Michael Catanzaro 2014-11-20 02:42:55 UTC 



+
Trace
    234351






Thread 1
          (Thread 0x7fb9a3df6700 (LWP 4071))


    

  • 
#0
g_logv

    
                at gmessages.c
                  line
                  1046

    

    • 

  • 
#1
g_log

    
                at gmessages.c
                  line
                  1079

    

    • 

  • 
#2
ephy_history_service_update_url_row

    
                at ephy-history-service-urls-table.c
                  line
                  203

    

    • 

  • 
#3
ephy_history_service_execute_set_url_thumbnail_time

    
                at ephy-history-service.c
                  line
                  997

    

    • 

  • 
#4
ephy_history_service_process_message

    
                at ephy-history-service.c
                  line
                  1280

    

    • 

  • 
#5
run_history_service_thread

    
                at ephy-history-service.c
                  line
                  526

    

    • 

  • 
#6
g_thread_proxy

    
                at gthread.c
                  line
                  764

    

    • 

  • 
#7
start_thread

    
                at pthread_create.c
                  line
                  310

    

    • 

  • 
#8
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  109

    

    • 













Comment 2


Michael Catanzaro





          2014-11-20 03:01:24 UTC
        



*** Bug 738308 has been marked as a duplicate of this bug. ***






Comment 3


Claudio Saavedra





          2014-11-20 08:59:57 UTC
        



Yes, it seems that's an overlook. I suppose for most cases we want to use g_warning() instead. I would probably double check, though, for which cases g_error() might still make sense. For database operations, probably not.






Comment 4


Michael Catanzaro





          2014-12-09 18:49:51 UTC
        



Created attachment 292405 [details] [review]
Don't crash when a database access fails

Database accesses can fail for many reasons, none of which merit a
crash. In particular, this should fix
https://bugzilla.redhat.com/show_bug.cgi?id=1065494






Comment 5


Claudio Saavedra





          2014-12-10 13:37:46 UTC
        



Review of attachment 292405 [details] [review]:

Thanks!