Re: Porting Corosync/Pacemaker - Help needed with gdb

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

Hi Manuel,

thanks, that makes sense. The failing instruction is this one

=> 0x7f7ff68078e9 <pthread_mutex_lock+9>:       mov    0x10(%rax),%rdx

with rax containing a pointer to 0x7f7ffffffffe

I wonder how many bytes will be written to memory - my imagination is 8 bytes as this is a 64bit processor.

Regards,

Stephan

2012/12/5 Manuel Bouyer <bouyer%antioche.eu.org@localhost>

On Wed, Dec 05, 2012 at 12:32:52PM +0100, Stephan wrote:
> 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

Nothing wrong here. You're trying to read 4 bytes. with x 0x7f7ffffffffd,
the last byte to be read is at the start of the next page (0x7f8000000000),
which is not mapped.

--
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--