Re: crash-5.0: Segmentation fault with x86_64_get_active_set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "ville mattila" <ville.mattila@xxxxxxxxxxxxx> wrote:
> >
> > > Hello,
> > >
> > > I get segementation fault from our 64-bit kernel crash
> > > This crash is caused by "echo c > /proc/sys-trigger".
> > > The reason seems to be that the x86_64_cpu_pda_init is
> > > not called at least gdb do not break there.

... [ snip ] ...

A patch for your initialization-time segmentation violation is attached.

... [ snip ] ...

But as for this one:

> 
> Btw, the "struct" command caused another segementation fault.
> Here is gdb bt:
> 
> (gdb) bt
> #0 0x00007f74b3524a92 in strcmp () from /lib/libc.so.6
> #1 0x0000000000534284 in lookup_partial_symtab (name=0x120e3c0 "x8664_pda") at symtab.c:276
> #2 0x00000000005344ed in lookup_symtab (name=0x120e3c0 "x8664_pda") at symtab.c:228
> #3 0x000000000060019d in c_lex () at c-exp.y:2149
> #4 0x00000000006008f5 in c_parse_internal () at c-exp.c.tmp:1468
> #5 0x00000000006022dd in c_parse () at c-exp.y:2225
> #6 0x000000000055f614 in parse_exp_in_context (stringptr=0x7fffbc2f2260, block=<value optimized out>, comma=<value optimized out>, void_context_p=0, out_subexp=0x0) at parse.c:1094
> #7 0x000000000055f924 in parse_expression (string=0x7fffbc2f2950 "x8664_pda") at parse.c:1144
> #8 0x000000000053291b in gdb_command_funnel (req=0xca2c00) at symtab.c:4992
> #9 0x00000000004c1740 in gdb_interface (req=0xca2c00) at gdb_interface.c:407
> #10 0x00000000004e9dca in datatype_info (name=0xb618a7 "x8664_pda", member=0x0, dm=0x7fffbc2f3620) at symbols.c:4146
> #11 0x00000000004eb1ee in arg_to_datatype (s=0xb618a7 "x8664_pda", dm=0x7fffbc2f3620, flags=524290) at symbols.c:4867
> #12 0x00000000004efa1b in cmd_datatype_common (flags=2048) at symbols.c:4664
> #13 0x000000000045efd9 in exec_command () at main.c:644 
> #14 0x000000000045f1fa in main_loop () at main.c:603
> #15 0x00000000005452a9 in captured_command_loop (data=0x120e3c0) at ./main.c:226
> #16 0x00000000005434e4 in catch_errors (func=0x5452a0 <captured_command_loop>, func_args=0x0, errstring=0x7f9d7c "", mask=<value optimized out>) at exceptions.c:520
> #17 0x0000000000544d36 in captured_main (data=<value optimized out>) at ./main.c:924
> #18 0x00000000005434e4 in catch_errors (func=0x544340 <captured_main>, func_args=0x7fffbc2f38b0, errstring=0x7f9d7c "", mask=<value optimized out>) at exceptions.c:520
> #19 0x000000000054412f in gdb_main_entry (argc=<value optimized out>, argv=<value optimized out>) at ./main.c:939
> #20 0x000000000045fece in main (argc=3, argv=0x7fffbc2f3a08) at main.c:517
> (gdb) frame 1
> #1 0x0000000000534284 in lookup_partial_symtab (name=0x120e3c0 "x8664_pda") at symtab.c:276
> 276 if (FILENAME_CMP (name, pst->filename) == 0)
> (gdb) p name
> $4 = 0x120e3c0 "x8664_pda"
> (gdb) p pst
> $5 = (struct partial_symtab *) 0x14d6040
> (gdb) p pst->filename
> $6 = 0x0
> (gdb) p *pst
> $7 = {next = 0x0, filename = 0x0, fullname = 0x0, dirname = 0x0,
> objfile = 0x0, section_offsets = 0x0, textlow = 0, texthigh = 0,
> dependencies = 0x0, number_of_dependencies = 0, globals_offset = 0,
> n_global_syms = 0, statics_offset = 0, n_static_syms = 0, symtab = 0x0,
> read_symtab = 0, read_symtab_private = 0x0, readin = 0 '\0'}
> (gdb)

I cannot reproduce it, even with your supplied kernel/dumpfile pair:

  # crash vmlinux-2.6.31.7+up-syms kerneldump-20100114-091104
  
  ... [ snip ] ...
  
  crash> struct x8664_pda
  struct: invalid data structure reference: x8664_pda
  crash>

While walking through the "ALL_PSYMTABS" list of partial_symtabs in
lookup_partial_symtab(), I never see a NULL-filled partial_symtab
structure as you show above.  What I do see is 13434 partial_symtab
structures, with pst->filenames starting from: 

 /workarea5/work/fw/mulperi/ararat/kernel/sg-kernel.git/arch/x86/lib/csum-copy_64.S

until the last one:

 /workarea5/work/fw/mulperi/ararat/kernel/sg-kernel.git/arch/x86/kernel/head_64.S

So I don't know what the deal is with that one.

Dave


Index: x86_64.c
===================================================================
RCS file: /nfs/projects/cvs/crash/x86_64.c,v
retrieving revision 1.136
diff -u -p -r1.136 x86_64.c
--- x86_64.c	21 Dec 2009 16:21:11 -0000	1.136
+++ x86_64.c	19 Jan 2010 19:43:30 -0000
@@ -794,15 +794,36 @@ x86_64_per_cpu_init(void)
 	int i, cpus, cpunumber;
 	struct machine_specific *ms;
 
-	if (!(kt->flags & PER_CPU_OFF))
+	ms = machdep->machspec;
+
+	if (!(kt->flags & PER_CPU_OFF)) {
+		/*
+		 * Presume kernel is !CONFIG_SMP.
+		 */
+		if (symbol_exists("per_cpu__irq_stack_union")) { 
+			ms->stkinfo.ibase[0] = 
+				symbol_value("per_cpu__irq_stack_union");  
+			if ((ms->stkinfo.isize = 
+		    	    MEMBER_SIZE("irq_stack_union", "irq_stack")) <= 0)
+				ms->stkinfo.isize = 16384;
+		}
+		if (DUMPFILE() && symbol_exists("per_cpu__current_task")) {
+			if (!(ms->current = calloc(kt->cpus, sizeof(ulong))))
+				error(FATAL, 
+			    	    "cannot calloc"
+				    " %d x86_64 current pointers!\n",
+					kt->cpus);
+			get_symbol_data("per_cpu__current_task", sizeof(ulong),
+				&ms->current[0]);
+		}
+
 		return;
+	}
 
 	if (!symbol_exists("per_cpu__cpu_number") || 
 	    !symbol_exists("per_cpu__irq_stack_union"))
 		return;
 
-        ms = machdep->machspec;
-
 	for (i = cpus = 0; i < NR_CPUS; i++) {
 		if (!readmem(symbol_value("per_cpu__cpu_number") + 
 		    kt->__per_cpu_offset[i],
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux