Re: Porting Corosync/Pacemaker - Help needed with gdb

[Stephan <stephanwib%googlemail.com@localhost>]

I suspect that there is something wrong with the stack. According to pmap, and that seems to apply to all processes on NetBSD 6.0 amd64, the corosync process has the following stack regions:


00007f7ff8001000-00007f7ff8001fff       4k 0000000000000000 ---p+ (rwx) 1/0/0 00:00       0 -   [ stack ]
00007f7ff8002000-00007f7ff800ffff      56k 0000000000000000 rw-p+ (rwx) 1/0/0 00:00       0 -   [ stack ]
00007f7ff8010000-00007f7ffffdffff  130880k 0000000000000000 rw-p+ (rwx) 1/0/0 00:00       0 -   [ stack ]
00007f7ffffe0000-00007f7fffffffff     128k 0000000000000000 rw-p- (rwx) 1/0/0 00:00       0 -   [ stack ]


Our pointer points to 0x7f7ffffffffe, which resides in the last region - so it should be valid. But when using gdb, I can read the adresses up to 0x7f7ffffffffc while d, e and f are inaccessible:

(gdb) x 0x7f7ffffffffc
0x7f7ffffffffc: 0xfffffe81
(gdb) x 0x7f7ffffffffd
0x7f7ffffffffd: Cannot access memory at address 0x7f7ffffffffd
(gdb) x 0x7f7ffffffffe
0x7f7ffffffffe: Cannot access memory at address 0x7f7ffffffffe
(gdb) x 0x7f7fffffffff
0x7f7fffffffff: Cannot access memory at address 0x7f7fffffffff


It seems that this applies to all processes. Also forwarding this to tech-kern.

I hope someone can help.


Regards,

Stephan

2012/12/5 Stephan <stephanwib%googlemail.com@localhost>

Some deeper insight:

-----8<--------

Core was generated by `corosync'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f7ff68078e9 in pthread_mutex_lock () from /usr/lib/libpthread.so.1
(gdb) bt
#0  0x00007f7ff68078e9 in pthread_mutex_lock () from /usr/lib/libpthread.so.1

#1  0x00007f7ff7002e14 in ipc_thread_active (conn=0x7f7ff7391000) at coroipcs.c:465
#2  pthread_ipc_consumer (conn=0x7f7ff7391000) at coroipcs.c:674

#3  0x00007f7ff6809d75 in ?? () from /usr/lib/libpthread.so.1
#4  0x00007f7ff60759f0 in ___lwp_park50 () from /usr/lib/libc.so.12

Cannot access memory at address 0x7f7ff0000000
(gdb) x/10i 0x00007f7ff68078e0
   0x7f7ff68078e0 <pthread_mutex_lock>: mov    %fs:0x0,%rax
=> 0x7f7ff68078e9 <pthread_mutex_lock+9>:       mov    0x10(%rax),%rdx
   0x7f7ff68078ed <pthread_mutex_lock+13>:      xor    %eax,%eax
   0x7f7ff68078ef <pthread_mutex_lock+15>:      lock cmpxchg %rdx,0x10(%rdi)
   0x7f7ff68078f5 <pthread_mutex_lock+21>:      test   %rax,%rax
   0x7f7ff68078f8 <pthread_mutex_lock+24>:      jne    0x7f7ff68078fd <pthread_mutex_lock+29>
   0x7f7ff68078fa <pthread_mutex_lock+26>:      xor    %eax,%eax
   0x7f7ff68078fc <pthread_mutex_lock+28>:      retq
   0x7f7ff68078fd <pthread_mutex_lock+29>:      jmpq   0x7f7ff6807640
   0x7f7ff6807902:      data32 data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
(gdb) info reg rax rdx
rax            0x7f7ffffffffe   140187732541438
rdx            0x0      0
(gdb) x/p 0x7f7ffffffffe
0x7f7ffffffffe: Cannot access memory at address 0x7f7ffffffffe
------------------------


If I understand correctly, the crash happens when the content of rdx is copied to the adress rax points to. And rax points to 0x7f7ffffffffe, which is indeed not present. Also I wonder why gdb says "Cannot access memory at address 0x7f7ff0000000" when doing a backtrace.

Ideas?