Bug 1121142 - [abrt] easytag: gtk_tree_store_get_path(): easytag killed by SIGSEGV
Summary: [abrt] easytag: gtk_tree_store_get_path(): easytag killed by SIGSEGV
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: easytag
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David King
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:bb0acd5bf78d95295599529c082...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-18 13:20 UTC by code
Modified: 2014-10-13 21:37 UTC (History)
3 users (show)

Fixed In Version: easytag-2.2.4-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-08 19:06:32 UTC


Attachments (Terms of Use)
File: backtrace (46.39 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: cgroup (181 bytes, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: core_backtrace (19.50 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: dso_list (10.37 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: environ (1.78 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: exploitable (82 bytes, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: limits (1.29 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: maps (54.16 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: open_fds (1.39 KB, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: proc_pid_status (943 bytes, text/plain)
2014-07-18 13:20 UTC, code
no flags Details
File: var_log_messages (394 bytes, text/plain)
2014-07-18 13:20 UTC, code
no flags Details

Description code 2014-07-18 13:20:44 UTC
Description of problem:
Attempted to “Reload Tree” after some directories had been removed. Not obvious how to reproduce the problem.

Version-Release number of selected component:
easytag-2.2.3-1.fc20

Additional info:
reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        easytag
crash_function: gtk_tree_store_get_path
executable:     /usr/bin/easytag
kernel:         3.15.3-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 gtk_tree_store_get_path at gtktreestore.c:592
 #2 gtk_tree_store_remove at gtktreestore.c:1227
 #3 gtk_tree_store_clear_traverse at gtktreestore.c:1856
 #10 gtk_tree_store_clear at gtktreestore.c:1884
 #11 Browser_Tree_Initialize at src/browser.c:2513
 #12 Browser_Tree_Rebuild at src/browser.c:2642
 #17 _gtk_action_emit_activate at deprecated/gtkaction.c:906
 #22 gtk_widget_activate at gtkwidget.c:7199
 #23 gtk_menu_shell_activate_item at gtkmenushell.c:1391
 #24 gtk_menu_shell_button_release at gtkmenushell.c:805

Comment 1 code 2014-07-18 13:20:46 UTC
Created attachment 919074 [details]
File: backtrace

Comment 2 code 2014-07-18 13:20:46 UTC
Created attachment 919075 [details]
File: cgroup

Comment 3 code 2014-07-18 13:20:47 UTC
Created attachment 919076 [details]
File: core_backtrace

Comment 4 code 2014-07-18 13:20:48 UTC
Created attachment 919077 [details]
File: dso_list

Comment 5 code 2014-07-18 13:20:48 UTC
Created attachment 919078 [details]
File: environ

Comment 6 code 2014-07-18 13:20:49 UTC
Created attachment 919079 [details]
File: exploitable

Comment 7 code 2014-07-18 13:20:50 UTC
Created attachment 919080 [details]
File: limits

Comment 8 code 2014-07-18 13:20:51 UTC
Created attachment 919081 [details]
File: maps

Comment 9 code 2014-07-18 13:20:51 UTC
Created attachment 919082 [details]
File: open_fds

Comment 10 code 2014-07-18 13:20:52 UTC
Created attachment 919083 [details]
File: proc_pid_status

Comment 11 code 2014-07-18 13:20:52 UTC
Created attachment 919084 [details]
File: var_log_messages

Comment 12 David King 2014-07-18 14:33:14 UTC
This is probably because the browser tree is cleared (as part of the "reload tree" process) and the selection changes, which then triggers reading of the removed rows from the model. I can't reproduce a crash, but I can reproduce some odd behaviour when removing the directory for a selected row during runtime, and then calling "reload tree".

I just created a patch which fixes the behaviour for me, so please test the following scratch build and let me know if it works for you:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7162274

Comment 13 code 2014-07-22 12:29:08 UTC
Hard to be sure of a “fix” since I had no technique for reproducing the original crash, but I’ll use this for a few days in a similar workflow and report whether the reload tree seems stable and well behaved. Thanks!

Comment 14 David King 2014-07-22 12:36:46 UTC
Thanks! Just to be clear, by steps to reproduce (given that I could only reproduce a constant reloading of the directory tree, not a crash) were:

1. mkdir foo
2. launch EasyTAG
3. select foo in the directory list
4. rmdir foo
5. reload tree

If the crash turns out to be something different, which it might be, steps to reproduce would be fantastic.

Comment 15 code 2014-07-28 13:18:56 UTC
I also encountered the constant reloading loop you mentioned. The scratch build you posted seems to have fixed that, and testing so far has not produced any segfaults either. I think this is probably fixed. Thanks!

Comment 16 David King 2014-07-30 10:09:12 UTC
Thanks for the confirmation. I pushed the patch upstream, and it will be in the next stable update for the easytag package, together with the eventual fix for bug 1121142.

https://git.gnome.org/browse/easytag/commit/?id=ef9c43474c36c7660e67420bba514559bf7163a3

Comment 17 Fedora Update System 2014-09-27 10:13:45 UTC
easytag-2.2.4-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc21

Comment 18 Fedora Update System 2014-09-27 10:21:19 UTC
easytag-2.2.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc20

Comment 19 Fedora Update System 2014-09-27 10:59:43 UTC
easytag-2.2.4-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc19

Comment 20 Fedora Update System 2014-09-27 11:01:11 UTC
easytag-2.2.4-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/easytag-2.2.4-1.el7

Comment 21 Fedora Update System 2014-09-28 04:29:56 UTC
Package easytag-2.2.4-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing easytag-2.2.4-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11767/easytag-2.2.4-1.fc20
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2014-09-30 01:54:46 UTC
easytag-2.2.4-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2014-10-08 19:05:57 UTC
easytag-2.2.4-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Fedora Update System 2014-10-08 19:06:32 UTC
easytag-2.2.4-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 25 Fedora Update System 2014-10-13 21:37:11 UTC
easytag-2.2.4-1.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.