[REGRESSION]: hibernation issues on 3.5.4/3.5.5
Hello. I am experiencing problems with hibernation (echo disk > /sys/power/state) on both 3.5.4 and 3.5.5. Note: Problem did not exist up through 3.5.2 (I skipped 3.5.3). Upon resume from hibernation, the % loading progress indicator appears. At some point the image stops loading and the system reverts to a standard cold-boot sequence. Logs (attached below) reveal it is erroring out with "Invalid LZO uncompressed length". Many thanks for your help. ~ Andy === [2.354392] PM: Checking hibernation image partition /dev/hda2 [2.354414] PM: Hibernation image partition 3:2 present [2.354415] PM: Looking for hibernation image. [2.379577] PM: Image signature found, resuming [2.406288] PM: Marking nosave pages: [mem 0x0009f000-0x000f] [2.406294] PM: Basic memory bitmaps created [2.406295] PM: Preparing processes for restore. [2.406298] Freezing user space processes ... (elapsed 0.00 seconds) done. [2.406604] PM: Loading hibernation image. [3.162702] PM: Using 1 thread(s) for decompression. [3.162702] PM: Loading and decompressing image data (161994 pages) ... ^H^H^H^H 0%%^H^H^H^H 1%%^H^H^H^H 2%%^H^H^H^H 3%%^H^H^H^H 4%%^H^H^H^H 5%%^H^H^H^H 6%%^H^H^H^H 7%%^H^H^H^H 8%%^H^H^H^H 9%%^H^H^H^H 10%%^H^H^H^H 11%%^H^H^H^H 12%%^H^H^H^H 13%%^H^H^H^H 14%%^H^H^H^H 15%%^H^H^H^H 16%%^H^H^H^H 17%%^H^H^H^H 18%%^H^H^H^H 19%%^H^H^H^H 20%%^H^H^H^H 21%%^H^H^H^H 22%%^H^H^H^H 23%%^H^H^H^H 24%%^H^H^H^H 25%%^H^H^H^H 26%%^H^H^H^H 27%%^H^H^H^H 28%%^H^H^H^H 29%%^H^H^H^H 30%%^H^H^H^H 31%%^H^H^H^H 32%%^H^H^H^H 33%%^H^H^H^H 34%%^H^H^H^H 35%%^H^H^H^H 36%%^H^H^H^H 37%%^H^H^H^H 38%%^H^H^H^H 39%%^H^H^H^H 40%%^H^H^H^H 41%%^H^H^H^H 42%%^H^H^H^H 43%%^H^H^H^H 44%%^H^H^H^H 45%%^H^H^H^H 46%%^H^H^H^H 47%%^H^H^H^H 48%%^H^H^H^H 49%%^H^H^H^H 50%%^H^H^H^H 51%%^H^H^H^H 52%%^H^H^H^H 53%%^H^H^H^H 54%%^H^H^H^H 55%%^H^H^H^H 56%%^H^H^H^H 57%%^H^H^H^H 58%%^H^H^H^H 59%%^H^H^H^H 60%%^H^H^H^H 61%%^H^H^H^H 62%% [7.730534] PM: Invalid LZO uncompressed length [7.730743] [7.730880] PM: Read 647976 kbytes in 4.56 seconds (142.10 MB/s) [7.731616] PM: Error -1 resuming [8.224207] PM: Failed to load hibernation image, recovering. [8.279520] Restarting tasks ... done. [8.279783] PM: Basic memory bitmaps freed [8.306034] PM: Hibernation image not present or could not be loaded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION]: hibernation issues on 3.5.4/3.5.5
Hello. I am experiencing problems with hibernation (echo disk /sys/power/state) on both 3.5.4 and 3.5.5. Note: Problem did not exist up through 3.5.2 (I skipped 3.5.3). Upon resume from hibernation, the % loading progress indicator appears. At some point the image stops loading and the system reverts to a standard cold-boot sequence. Logs (attached below) reveal it is erroring out with Invalid LZO uncompressed length. Many thanks for your help. ~ Andy === [2.354392] PM: Checking hibernation image partition /dev/hda2 [2.354414] PM: Hibernation image partition 3:2 present [2.354415] PM: Looking for hibernation image. [2.379577] PM: Image signature found, resuming [2.406288] PM: Marking nosave pages: [mem 0x0009f000-0x000f] [2.406294] PM: Basic memory bitmaps created [2.406295] PM: Preparing processes for restore. [2.406298] Freezing user space processes ... (elapsed 0.00 seconds) done. [2.406604] PM: Loading hibernation image. [3.162702] PM: Using 1 thread(s) for decompression. [3.162702] PM: Loading and decompressing image data (161994 pages) ... ^H^H^H^H 0%%^H^H^H^H 1%%^H^H^H^H 2%%^H^H^H^H 3%%^H^H^H^H 4%%^H^H^H^H 5%%^H^H^H^H 6%%^H^H^H^H 7%%^H^H^H^H 8%%^H^H^H^H 9%%^H^H^H^H 10%%^H^H^H^H 11%%^H^H^H^H 12%%^H^H^H^H 13%%^H^H^H^H 14%%^H^H^H^H 15%%^H^H^H^H 16%%^H^H^H^H 17%%^H^H^H^H 18%%^H^H^H^H 19%%^H^H^H^H 20%%^H^H^H^H 21%%^H^H^H^H 22%%^H^H^H^H 23%%^H^H^H^H 24%%^H^H^H^H 25%%^H^H^H^H 26%%^H^H^H^H 27%%^H^H^H^H 28%%^H^H^H^H 29%%^H^H^H^H 30%%^H^H^H^H 31%%^H^H^H^H 32%%^H^H^H^H 33%%^H^H^H^H 34%%^H^H^H^H 35%%^H^H^H^H 36%%^H^H^H^H 37%%^H^H^H^H 38%%^H^H^H^H 39%%^H^H^H^H 40%%^H^H^H^H 41%%^H^H^H^H 42%%^H^H^H^H 43%%^H^H^H^H 44%%^H^H^H^H 45%%^H^H^H^H 46%%^H^H^H^H 47%%^H^H^H^H 48%%^H^H^H^H 49%%^H^H^H^H 50%%^H^H^H^H 51%%^H^H^H^H 52%%^H^H^H^H 53%%^H^H^H^H 54%%^H^H^H^H 55%%^H^H^H^H 56%%^H^H^H^H 57%%^H^H^H^H 58%%^H^H^H^H 59%%^H^H^H^H 60%%^H^H^H^H 61%%^H^H^H^H 62%% [7.730534] PM: Invalid LZO uncompressed length [7.730743] [7.730880] PM: Read 647976 kbytes in 4.56 seconds (142.10 MB/s) [7.731616] PM: Error -1 resuming [8.224207] PM: Failed to load hibernation image, recovering. [8.279520] Restarting tasks ... done. [8.279783] PM: Basic memory bitmaps freed [8.306034] PM: Hibernation image not present or could not be loaded. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG]: fsnotify oops on 3.5.2
On Mon, Aug 27, 2012 at 02:34:28PM -0400, Steven Rostedt wrote: > > Thanks for pointing out that the kernel is patched with overlayfs. As > the crash is within the filesystem, it looks to be a bug with that > patch. You may want to report this bug to them. > > -- Steve You were right. After reverting to 3.5.2 (sans overlayfs) the oops stopped. I will contact the overlyafs folks on the fs-devel list and let them know. ~ Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG]: fsnotify oops on 3.5.2
On Mon, Aug 27, 2012 at 02:34:28PM -0400, Steven Rostedt wrote: Thanks for pointing out that the kernel is patched with overlayfs. As the crash is within the filesystem, it looks to be a bug with that patch. You may want to report this bug to them. -- Steve You were right. After reverting to 3.5.2 (sans overlayfs) the oops stopped. I will contact the overlyafs folks on the fs-devel list and let them know. ~ Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG]: fsnotify oops on 3.5.2
On Mon, Aug 27, 2012 at 01:32:01PM +0800, Guo Chao wrote: > Problematic instruction seems to be this one: > >85 73 74 test %esi,0x74(%ebx) Guo: Thank you very much for the very detailed response on the meaning of the oops - it was very educational for me. I did have one question, however. How were you able to identify the relevant section in the source code? > But have no idea how 'struct path' contained a NULL > 'struct vfsmount *' ... ... > As Steven points out, this could be a bug in the overlayfs code. After getting a 2nd oops last night, I rebuilt 3.5.2 w/o overlafs in order to test that theory. Though I am unable to reproduce at will, 2 oopses in 60 hours suggests I should not have to wait too long for a verdict. I will follow-up in a couple of days one way or the other. ~ Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG]: fsnotify oops on 3.5.2
On Mon, Aug 27, 2012 at 01:32:01PM +0800, Guo Chao wrote: Problematic instruction seems to be this one: 85 73 74 test %esi,0x74(%ebx) Guo: Thank you very much for the very detailed response on the meaning of the oops - it was very educational for me. I did have one question, however. How were you able to identify the relevant section in the source code? But have no idea how 'struct path' contained a NULL 'struct vfsmount *' ... ... As Steven points out, this could be a bug in the overlayfs code. After getting a 2nd oops last night, I rebuilt 3.5.2 w/o overlafs in order to test that theory. Though I am unable to reproduce at will, 2 oopses in 60 hours suggests I should not have to wait too long for a verdict. I will follow-up in a couple of days one way or the other. ~ Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG]: fsnotify oops on 3.5.2
Hi. Last night I had a kernel oops in fsnotify (see attached). It happened when I clicked a hyperlink to a text file in Firefox (which normally opens an open-with/save-file dialog). I've not found a way to reproduce. The system runs kernel 3.5.2 with ext3. (note: kernel is patched with overlayfs-v13). Many thanks for your assistance. ~ Andy == BUG: unable to handle kernel NULL pointer dereference at 0064 IP: [] fsnotify+0x8b/0x270 *pde = Oops: [#1] Pid: 14083, comm: firefox Tainted: G O 3.5.2 EIP: 0060:[] EFLAGS: 00210246 CPU: 0 EIP is at fsnotify+0x8b/0x270 EAX: EBX: fff0 ECX: f5988910 EDX: f5988910 ESI: 0010 EDI: EBP: dea1de5c ESP: dea1de14 DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 CR0: 80050033 CR2: 0064 CR3: 34c52000 CR4: 07d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process firefox (pid: 14083, ti=dea1c000 task=ed2d1880 task.ti=dea1c000) Stack: dea1de34 c10ee498 dea1deec dea1df78 8000 0001 c10f21c3 eeb43688 f5988910 0010 dea1de48 eeb43680 0010 f6003600 dea1de8c c10de255 0001 Call Trace: [] ? dput+0x156/0x1c5 [] ? mntput+0x19/0x28 [] fput+0x196/0x1ed [] release_open_intent+0x1d/0x29 [] path_openat+0xc5/0x33f [] do_filp_open+0x2a/0x79 [] ? alloc_fd+0x5c/0xcb [] ? getname_flags+0x31/0xb1 [] do_sys_open+0xef/0x1da [] sys_open+0x27/0x2f [] sysenter_do_call+0x12/0x22 [] ? netlbl_mgmt_add_common+0x1ec/0x306 Code: 02 00 00 b8 20 82 93 c1 e8 41 35 f4 ff 89 45 d0 8b 4d dc 85 b1 24 01 00 00 0f 85 2b 01 00 00 85 db 0f 84 37 01 00 00 85 ff 75 09 <85> 73 74 0f 84 2a 01 00 00 8b 43 70 89 45 ec 8b 4d dc 8b 91 28 EIP: [] fsnotify+0x8b/0x270 SS:ESP 0068:dea1de14 CR2: 0064 ---[ end trace b9a1d764aab1963e ]---
[BUG]: fsnotify oops on 3.5.2
Hi. Last night I had a kernel oops in fsnotify (see attached). It happened when I clicked a hyperlink to a text file in Firefox (which normally opens an open-with/save-file dialog). I've not found a way to reproduce. The system runs kernel 3.5.2 with ext3. (note: kernel is patched with overlayfs-v13). Many thanks for your assistance. ~ Andy == BUG: unable to handle kernel NULL pointer dereference at 0064 IP: [c1109b7d] fsnotify+0x8b/0x270 *pde = Oops: [#1] Pid: 14083, comm: firefox Tainted: G O 3.5.2 EIP: 0060:[c1109b7d] EFLAGS: 00210246 CPU: 0 EIP is at fsnotify+0x8b/0x270 EAX: EBX: fff0 ECX: f5988910 EDX: f5988910 ESI: 0010 EDI: EBP: dea1de5c ESP: dea1de14 DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 CR0: 80050033 CR2: 0064 CR3: 34c52000 CR4: 07d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process firefox (pid: 14083, ti=dea1c000 task=ed2d1880 task.ti=dea1c000) Stack: dea1de34 c10ee498 dea1deec dea1df78 8000 0001 c10f21c3 eeb43688 f5988910 0010 dea1de48 eeb43680 0010 f6003600 dea1de8c c10de255 0001 Call Trace: [c10ee498] ? dput+0x156/0x1c5 [c10f21c3] ? mntput+0x19/0x28 [c10de255] fput+0x196/0x1ed [c10e5435] release_open_intent+0x1d/0x29 [c10e8b03] path_openat+0xc5/0x33f [c10e8e41] do_filp_open+0x2a/0x79 [c10f105e] ? alloc_fd+0x5c/0xcb [c10e538a] ? getname_flags+0x31/0xb1 [c10dc553] do_sys_open+0xef/0x1da [c10dc692] sys_open+0x27/0x2f [c1573f13] sysenter_do_call+0x12/0x22 [c156] ? netlbl_mgmt_add_common+0x1ec/0x306 Code: 02 00 00 b8 20 82 93 c1 e8 41 35 f4 ff 89 45 d0 8b 4d dc 85 b1 24 01 00 00 0f 85 2b 01 00 00 85 db 0f 84 37 01 00 00 85 ff 75 09 85 73 74 0f 84 2a 01 00 00 8b 43 70 89 45 ec 8b 4d dc 8b 91 28 EIP: [c1109b7d] fsnotify+0x8b/0x270 SS:ESP 0068:dea1de14 CR2: 0064 ---[ end trace b9a1d764aab1963e ]---
Re: [SEGFAULT: perf]
Hi Namhyung. On Tue, Jul 24, 2012 at 09:18:24AM +0900, Namhyung Kim wrote: > > (A) has a fix already in the tip tree [1], and maybe in mainline too. Ah yes, I see the fix in 3.5 as well. Though it is slightly different from the patch I submitted. > And yes, I think this sort thing needs some love. It's on my TODO list > but not have time to do it yet. I understand all about time constraints. I am glad it is on your TODO though; will be on the lookout for commits on that front. Cheers. ~ Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SEGFAULT: perf]
Hi Namhyung. On Tue, Jul 24, 2012 at 09:18:24AM +0900, Namhyung Kim wrote: (A) has a fix already in the tip tree [1], and maybe in mainline too. Ah yes, I see the fix in 3.5 as well. Though it is slightly different from the patch I submitted. And yes, I think this sort thing needs some love. It's on my TODO list but not have time to do it yet. I understand all about time constraints. I am glad it is on your TODO though; will be on the lookout for commits on that front. Cheers. ~ Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SEGFAULT: perf]
perf report on 3.4.6 segfaults when certain pointers are null. Attached is
a patch that applies cleanly @3.4.6 and addresses (A). I am not comfortable
suggesting fixes for (B) and (C).
~ Andy
===
(A) perf report with sort on comm/pid/parent/dso:
(gdb) run report --sort=comm
Program received signal SIGSEGV, Segmentation fault.
0x0805c00b in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:171
171 if (notes->src == NULL && symbol__alloc_hist(he->ms.sym) < 0)
#0 0x0805c00b in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:171
#1 0x0805c234 in process_sample_event (tool=0xb27c, event=0xb6db1f38,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
#2 0x080a3097 in perf_session_deliver_event (session=0x81c3f50, event=
0xb6db1f38, sample=0xbfffea84, tool=0xb27c, file_offset=339768)
at util/session.c:885
#3 0x080a24d1 in flush_sample_queue (s=0x81c3f50, tool=0xb27c)
at util/session.c:587
#4 0x080a40e3 in __perf_session__process_events (session=0x81c3f50,
data_offset=280, data_size=419640, file_size=419920, tool=0xb27c)
at util/session.c:1257
#5 0x080a41d3 in perf_session__process_events (self=0x81c3f50, tool=
0xb27c) at util/session.c:1273
(gdb) print he->ms.sym
$1 = (struct symbol *) 0x0
--
(B) perf report segfaults on sorts of symbol_from/symbol_to:
(gdb) run report --sort=symbol_from
Program received signal SIGSEGV, Segmentation fault.
0x080b8777 in sort__sym_from_cmp (left=0xbfffe878, right=0x84dfde0)
at util/sort.c:334
334 if (!from_l->sym && !from_r->sym
(gdb) bt
#0 0x080b8777 in sort__sym_from_cmp (left=0xbfffe878, right=0x84dfde0)
at util/sort.c:334
#1 0x080ba0b8 in hist_entry__cmp (left=0xbfffe878, right=0x84dfde0)
at util/hist.c:345
#2 0x080b9c31 in add_hist_entry (hists=0x81c571c, entry=0xbfffe878, al=
0xbfffe9b0, period=333940) at util/hist.c:254
#3 0x080ba04c in __hists__add_entry (self=0x81c571c, al=0xbfffe9b0,
sym_parent=0x0, period=333940) at util/hist.c:335
#4 0x0805bf50 in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:149
#5 0x0805c234 in process_sample_event (tool=0xb27c, event=0xb6db1840,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
(gdb) print left->branch_info
$2 = (struct branch_info *) 0x0
(gdb) print right->branch_info
$3 = (struct branch_info *) 0x0
--
(C) perf report segfaults with dso_from/dso_to:
(gdb) run report --sort=dso_to
Program received signal SIGSEGV, Segmentation fault.
sort__dso_to_cmp (left=0xbfffe878, right=0x82346f0) at util/sort.c:317
317 return _sort__dso_cmp(left->branch_info->to.map,
(gdb) bt
#0 sort__dso_to_cmp (left=0xbfffe878, right=0x82346f0) at util/sort.c:317
#1 0x080ba0c8 in hist_entry__cmp (left=0xbfffe878, right=0x82346f0)
at util/hist.c:345
#2 0x080b9c41 in add_hist_entry (hists=0x81c571c, entry=0xbfffe878, al=
0xbfffe9b0, period=31) at util/hist.c:254
#3 0x080ba05c in __hists__add_entry (self=0x81c571c, al=0xbfffe9b0,
sym_parent=0x0, period=31) at util/hist.c:335
#4 0x0805bf50 in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:149
#5 0x0805c242 in process_sample_event (tool=0xb27c, event=0xb6dbf800,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
(gdb) print left->branch_info
$4 = (struct branch_info *) 0x0
(gdb) print right->branch_info
$5 = (struct branch_info *) 0x0
===
--- builtin-report.c.orig 2012-07-22
+++ builtin-report.c2012-07-22
@@ -162,7 +162,7 @@ static int perf_evsel__add_hist_entry(st
* so we don't allocated the extra space needed because the stdio
* code will not use it.
*/
- if (al->sym != NULL && use_browser > 0) {
+ if (al->sym != NULL && he->ms.sym != NULL && use_browser > 0) {
struct annotation *notes = symbol__annotation(he->ms.sym);
assert(evsel != NULL);
[SEGFAULT: perf]
perf report on 3.4.6 segfaults when certain pointers are null. Attached is
a patch that applies cleanly @3.4.6 and addresses (A). I am not comfortable
suggesting fixes for (B) and (C).
~ Andy
===
(A) perf report with sort on comm/pid/parent/dso:
(gdb) run report --sort=comm
Program received signal SIGSEGV, Segmentation fault.
0x0805c00b in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:171
171 if (notes-src == NULL symbol__alloc_hist(he-ms.sym) 0)
#0 0x0805c00b in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:171
#1 0x0805c234 in process_sample_event (tool=0xb27c, event=0xb6db1f38,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
#2 0x080a3097 in perf_session_deliver_event (session=0x81c3f50, event=
0xb6db1f38, sample=0xbfffea84, tool=0xb27c, file_offset=339768)
at util/session.c:885
#3 0x080a24d1 in flush_sample_queue (s=0x81c3f50, tool=0xb27c)
at util/session.c:587
#4 0x080a40e3 in __perf_session__process_events (session=0x81c3f50,
data_offset=280, data_size=419640, file_size=419920, tool=0xb27c)
at util/session.c:1257
#5 0x080a41d3 in perf_session__process_events (self=0x81c3f50, tool=
0xb27c) at util/session.c:1273
(gdb) print he-ms.sym
$1 = (struct symbol *) 0x0
--
(B) perf report segfaults on sorts of symbol_from/symbol_to:
(gdb) run report --sort=symbol_from
Program received signal SIGSEGV, Segmentation fault.
0x080b8777 in sort__sym_from_cmp (left=0xbfffe878, right=0x84dfde0)
at util/sort.c:334
334 if (!from_l-sym !from_r-sym
(gdb) bt
#0 0x080b8777 in sort__sym_from_cmp (left=0xbfffe878, right=0x84dfde0)
at util/sort.c:334
#1 0x080ba0b8 in hist_entry__cmp (left=0xbfffe878, right=0x84dfde0)
at util/hist.c:345
#2 0x080b9c31 in add_hist_entry (hists=0x81c571c, entry=0xbfffe878, al=
0xbfffe9b0, period=333940) at util/hist.c:254
#3 0x080ba04c in __hists__add_entry (self=0x81c571c, al=0xbfffe9b0,
sym_parent=0x0, period=333940) at util/hist.c:335
#4 0x0805bf50 in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:149
#5 0x0805c234 in process_sample_event (tool=0xb27c, event=0xb6db1840,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
(gdb) print left-branch_info
$2 = (struct branch_info *) 0x0
(gdb) print right-branch_info
$3 = (struct branch_info *) 0x0
--
(C) perf report segfaults with dso_from/dso_to:
(gdb) run report --sort=dso_to
Program received signal SIGSEGV, Segmentation fault.
sort__dso_to_cmp (left=0xbfffe878, right=0x82346f0) at util/sort.c:317
317 return _sort__dso_cmp(left-branch_info-to.map,
(gdb) bt
#0 sort__dso_to_cmp (left=0xbfffe878, right=0x82346f0) at util/sort.c:317
#1 0x080ba0c8 in hist_entry__cmp (left=0xbfffe878, right=0x82346f0)
at util/hist.c:345
#2 0x080b9c41 in add_hist_entry (hists=0x81c571c, entry=0xbfffe878, al=
0xbfffe9b0, period=31) at util/hist.c:254
#3 0x080ba05c in __hists__add_entry (self=0x81c571c, al=0xbfffe9b0,
sym_parent=0x0, period=31) at util/hist.c:335
#4 0x0805bf50 in perf_evsel__add_hist_entry (evsel=0x81c56a8, al=0xbfffe9b0,
sample=0xbfffea84, machine=0x81c3fa8) at builtin-report.c:149
#5 0x0805c242 in process_sample_event (tool=0xb27c, event=0xb6dbf800,
sample=0xbfffea84, evsel=0x81c56a8, machine=0x81c3fa8)
at builtin-report.c:216
(gdb) print left-branch_info
$4 = (struct branch_info *) 0x0
(gdb) print right-branch_info
$5 = (struct branch_info *) 0x0
===
--- builtin-report.c.orig 2012-07-22
+++ builtin-report.c2012-07-22
@@ -162,7 +162,7 @@ static int perf_evsel__add_hist_entry(st
* so we don't allocated the extra space needed because the stdio
* code will not use it.
*/
- if (al-sym != NULL use_browser 0) {
+ if (al-sym != NULL he-ms.sym != NULL use_browser 0) {
struct annotation *notes = symbol__annotation(he-ms.sym);
assert(evsel != NULL);
