Date: Mon, 1 Sep 2008 17:33:37 +0300 From: "Vyacheslav Bocharov" <adeepv@gmail.com> To: "Kostik Belousov" <kostikbel@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current Message-ID: <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> In-Reply-To: <20080831091639.GM2038@deviant.kiev.zoral.com.ua> References: <ed91d4a80808300946s49ff076dw64b57f8e9058f2d@mail.gmail.com> <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <ed91d4a80808301250j1a4802d4o412c6b5e30979079@mail.gmail.com> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <ed91d4a80808301403t5b776d10ubd184bc1ff01215@mail.gmail.com> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
I have similar problem in 7-STABLE (from 1 sep):
32bit application exec 64application and we have an core dump:
# gdb fw.sh fw.sh.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `fw.sh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1
(gdb) bt
#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1
#1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from
/lib/libc.so.7
#2 0x0000000800ada35f in malloc () from /lib/libc.so.7
#3 0x00000008007050ad in operator new () from /usr/lib/libstdc++.so.6
#4 0x00000008006b5f21 in std::string::_Rep::_S_create ()
from /usr/lib/libstdc++.so.6
#5 0x00000008006b6ca5 in std::string::_S_copy_chars ()
from /usr/lib/libstdc++.so.6
#6 0x00000008006b6dc2 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#7 0x00000000004021ec in __static_initialization_and_destruction_0 (
__initialize_p=1, __priority=65535) at CCmdLine.cpp:16
#8 0x00000000004026c3 in global constructors keyed to cmdlist ()
at CCmdLine.cpp:177
#9 0x00000000004033a2 in __do_global_ctors_aux ()
#10 0x000000000040113e in _init ()
#11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7
#12 0x00000000004014e8 in _start ()
#13 0x000000080052c000 in ?? ()
I tried your patch but nothing changed.
2008/8/31 Kostik Belousov <kostikbel@gmail.com>
> On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote:
> > On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote:
> > > With the new patch kernel has crashed as soon as I ran i386 app,
> > > though the crash happened within in-kernel thread g_up:
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 2; apic id = 02
> > > fault virtual address = 0x20
> > > fault code = supervisor read data, page not present
> > > instruction pointer = 0x8:0xffffffff804a821f
> > > stack pointer = 0x10:0xffffffffac280b60
> > > frame pointer = 0x10:0x0
> > > code segment = base 0x0, limit 0xfffff, type 0x1b
> > > = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags = resume, IOPL = 0
> > > current process = 3 (g_up)
> > > trap number = 12
> > > panic: page fault
> > > cpuid = 2
> > > Uptime: 37s
> > > Physical memory: 8169 MB
> > > Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 173
> > > 157 141 125 109 93 77 61 45 29 13
> > Could you, please, show me the disassembled code around the faulted
> > %rip ?
>
> No need, it seems I found the problem. I trashed the %rdx that contains
> the third cpu_switch argument. Please, try the updated patch.
>
> Thanks for the testing !
>
> diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
> index f34b0cc..03f0eca 100644
> --- a/sys/amd64/amd64/cpu_switch.S
> +++ b/sys/amd64/amd64/cpu_switch.S
> @@ -249,6 +249,12 @@ store_seg:
> 1: movl %ds,PCB_DS(%r8)
> movl %es,PCB_ES(%r8)
> movl %fs,PCB_FS(%r8)
> + movq %rdx,%r11
> + movl $MSR_FSBASE,%ecx
> + rdmsr
> + shlq $32,%rdx
> + leaq (%rax,%rdx),%r9
> + movq %r11,%rdx
> jmp done_store_seg
> 2: movq PCB_GS32P(%r8),%rax
> movq (%rax),%rax
>
--
Vyacheslav Bocharov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80861bfa0809010733h47580d3evb3eb68c972a2bb25>