[jira] [Commented] (IMPALA-7542) find-fragment-instances in impala-gdb.py misses to find the "root threads"
[ https://issues.apache.org/jira/browse/IMPALA-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609438#comment-16609438 ] ASF subversion and git services commented on IMPALA-7542: - Commit d19f75764140e3a0a7cd8db4f36791cf635b0dbc in impala's branch refs/heads/master from Zoltan Borok-Nagy [ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=d19f757 ] IMPALA-7542: fix find-fragment-instances to find all "root threads" find-fragment-instances didn't show all the threads that worked on some fragment instance. It missed the top-level "root threads" that started working on the fragment instances. I modified the get_fragment_instances() function to check the local ThreadDebugInfo object of the threads instead of checking the parent thread's ThreadDebugInfo. I tested it locally on a core file. Change-Id: I35ae1a6b384b002b343689469f02ceabd84af1b6 Reviewed-on: http://gerrit.cloudera.org:8080/11396 Reviewed-by: Impala Public Jenkins Tested-by: Impala Public Jenkins > find-fragment-instances in impala-gdb.py misses to find the "root threads" > -- > > Key: IMPALA-7542 > URL: https://issues.apache.org/jira/browse/IMPALA-7542 > Project: IMPALA > Issue Type: Bug >Reporter: Zoltán Borók-Nagy >Assignee: Zoltán Borók-Nagy >Priority: Major > > find-fragment-instances uses ThreadDebugInfo from IMPALA-6416 to find the > query ids and fragment ids currently being executed of an (probably crashed) > impalad. > To achieve that it traverses the stack frames of each thread and searches for > the stack frame of Thread::SuperviseThread(). This function has a > parent_thread_info parameter that points to its parent thread's > ThreadDebugInfo object. Then, checks what instance id the parent thread is > working on. > This is all good until the bottom of the thread hierarchy because threads > always work on the same fragment instance that their parent work on. > However, at the top of the hierarchy there is some "root thread" that starts > to work on a fragment instance, but its parent doesn't work on any. Since we > only check the parent thread's instance id we miss to catch this first thread. > Thread::SuperviseThread() also has a local ThreadDebugInfo that contains the > proper instance id, so we should use it instead of the parent's. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7542) find-fragment-instances in impala-gdb.py misses to find the "root threads"
[ https://issues.apache.org/jira/browse/IMPALA-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605617#comment-16605617 ] Zoltán Borók-Nagy commented on IMPALA-7542: --- Under review: [https://gerrit.cloudera.org/#/c/11396/] I also want to note that it still doesn't find all threads that work on some fragment instances, because threads that belong to thread pools aren't annotated currently. IMPALA-6417 is tracking this. > find-fragment-instances in impala-gdb.py misses to find the "root threads" > -- > > Key: IMPALA-7542 > URL: https://issues.apache.org/jira/browse/IMPALA-7542 > Project: IMPALA > Issue Type: Bug >Reporter: Zoltán Borók-Nagy >Assignee: Zoltán Borók-Nagy >Priority: Major > > find-fragment-instances uses ThreadDebugInfo from IMPALA-6416 to find the > query ids and fragment ids currently being executed of an (probably crashed) > impalad. > To achieve that it traverses the stack frames of each thread and searches for > the stack frame of Thread::SuperviseThread(). This function has a > parent_thread_info parameter that points to its parent thread's > ThreadDebugInfo object. Then, checks what instance id the parent thread is > working on. > This is all good until the bottom of the thread hierarchy because threads > always work on the same fragment instance that their parent work on. > However, at the top of the hierarchy there is some "root thread" that starts > to work on a fragment instance, but its parent doesn't work on any. Since we > only check the parent thread's instance id we miss to catch this first thread. > Thread::SuperviseThread() also has a local ThreadDebugInfo that contains the > proper instance id, so we should use it instead of the parent's. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
