On Wed, Nov 24, 2004 at 02:11:49AM +0000, Ian Pratt wrote:
> > dom1 is running arch--boots fine but applications linked to pthread
> > segfault when pthread goes to access gs. I would think that this is the
> > tls problem, but i renamed tls.
>
> What happens if you don't move tls out the way? It'll be slower,
> but should work. (is it falling back to 686? -- "ldd /bin/sleep"
> will tell you).
ah, that works!
> What glibc version is it using?
2.3.3
> Can you get a debugger to look at the operands to the faulting
> instuction.
# gdb ls
GNU gdb 6.2.1
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 "i686-pc-linux-gnu"...(no debugging symbols
found)...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /bin/ls
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 260)]
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 260)]
0xb7e56d43 in _pthread_cleanup_push_defer () from /lib/libpthread.so.0
(gdb) bt
#0 0xb7e56d43 in _pthread_cleanup_push_defer () from /lib/libpthread.so.0
#1 0xb7f0d35b in _IO_link_in_internal () from /lib/libc.so.6
#2 0xb7f0abd6 in _IO_new_file_init () from /lib/libc.so.6
#3 0xb7f010ec in __fopen_internal () from /lib/libc.so.6
#4 0xb7f0115d in fopen@@GLIBC_2.1 () from /lib/libc.so.6
#5 0xb7f7303b in setmntent () from /lib/libc.so.6
#6 0xb7f77e29 in get_proc_path () from /lib/libc.so.6
#7 0xb7f7819e in phys_pages_info () from /lib/libc.so.6
#8 0xb7f4a394 in posix_sysconf () from /lib/libc.so.6
#9 0xb7f4a718 in sysconf () from /lib/libc.so.6
#10 0xb7ecd7ec in qsort () from /lib/libc.so.6
#11 0x0804a7bc in ?? ()
...
(gdb) disassemble 0xb7e56d43
Dump of assembler code for function _pthread_cleanup_push_defer:
0xb7e56d30 <_pthread_cleanup_push_defer+0>: push %ebp
0xb7e56d31 <_pthread_cleanup_push_defer+1>: mov %esp,%ebp
0xb7e56d33 <_pthread_cleanup_push_defer+3>: mov 0x8(%ebp),%edx
0xb7e56d36 <_pthread_cleanup_push_defer+6>: mov 0xc(%ebp),%eax
0xb7e56d39 <_pthread_cleanup_push_defer+9>: mov %eax,(%edx)
0xb7e56d3b <_pthread_cleanup_push_defer+11>: mov 0x10(%ebp),%eax
0xb7e56d3e <_pthread_cleanup_push_defer+14>: mov %eax,0x4(%edx)
0xb7e56d41 <_pthread_cleanup_push_defer+17>: xor %eax,%eax
0xb7e56d43 <_pthread_cleanup_push_defer+19>: mov %gs:0x81,%al
0xb7e56d49 <_pthread_cleanup_push_defer+25>: movsbl %al,%eax
0xb7e56d4c <_pthread_cleanup_push_defer+28>: mov %eax,0x8(%edx)
0xb7e56d4f <_pthread_cleanup_push_defer+31>: mov %gs:0x7c,%eax
...
(gdb) info reg
eax 0x0 0
ecx 0x0 0
edx 0xbfffd648 -1073752504
ebx 0xb7fd1044 -1208151996
esp 0xbfffd634 0xbfffd634
ebp 0xbfffd634 0xbfffd634
esi 0x805e720 134604576
edi 0x1 1
eip 0xb7e56d43 0xb7e56d43
eflags 0x10246 66118
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
--
Scott R. Parish
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home