Nabble - Gnu - gdb

I think this is a hehavior of kernel.  I think change pc always a
danger thing.  :)

infrun: clear_proceed_status_thread (process 4542)
infrun: proceed (addr=0xffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun:   4542 [process 4542],
infrun:   status->kind = stopped, signal = SIGINT
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xb7fe3410
infrun: random signal 2

Program received signal SIGINT, Interrupt.
infrun: stop_stepping
0xb7fe3410 in __kernel_vsyscall ()
(gdb) disas
Dump of assembler code for function __kernel_vsyscall:
   0xb7fe3400 <+0>:	push   %ecx
   0xb7fe3401 <+1>:	push   %edx
   0xb7fe3402 <+2>:	push   %ebp
   0xb7fe3403 <+3>:	mov    %esp,%ebp
   0xb7fe3405 <+5>:	sysenter
   0xb7fe3407 <+7>:	nop
   0xb7fe3408 <+8>:	nop
   0xb7fe3409 <+9>:	nop
   0xb7fe340a <+10>:	nop
   0xb7fe340b <+11>:	nop
   0xb7fe340c <+12>:	nop
   0xb7fe340d <+13>:	nop
   0xb7fe340e <+14>:	jmp    0xb7fe3403 <__kernel_vsyscall+3>
=> 0xb7fe3410 <+16>:	pop    %ebp
   0xb7fe3411 <+17>:	pop    %edx
   0xb7fe3412 <+18>:	pop    %ecx
   0xb7fe3413 <+19>:	ret
End of assembler dump.
(gdb) p $pc
$1 = (void (*)()) 0xb7fe3410 <__kernel_vsyscall+16>
(gdb) p $pc=0xb7fe3413
$2 = (void (*)()) 0xb7fe3413 <__kernel_vsyscall+19>
(gdb) si
infrun: clear_proceed_status_thread (process 4542)
infrun: proceed (addr=0xffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun:   4542 [process 4542],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xb7fe3412
infrun: stepi/nexti
infrun: stop_stepping
0xb7fe3412 in __kernel_vsyscall ()

Thanks,
Hui

On Nov 2, 7:27 pm, Alexandre Rusev aru...@... wrote:

teawater wrote:

This signal ctrl-c will not really send to inferior.

But the result is interrupted system call which is restarted then by kernel.
And is user changes program counter in GDB at this point,
then it takes place before the modification of PC is done by kernel.
The result is that execution jumps neither to the point the user said in
GDB nor
to the point the kernel wishes it be due to restart the syscall.

Is it incorrect behavior of GDB or incorrect behavior of kernel or
something else???

(gdb) help info handle

On Oct 31, 12:10 am, Alexandre Rusev aru...@... wrote:

Hi.

When the program at ht end of message debugged under GDB is stopped with
Ctrl+C
it's usually found in interrupted system call. (The same result is
observed for x86 and PPC with kernels 2.6.18 and 2.6.28)

(gdb) where
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7f36ad0 in nanosleep () from /lib/libc.so.6
#2  0xb7f3690e in sleep () from /lib/libc.so.6
#3  0x08048600 in qqq () at testBT2.c:45
#4  0x080487a5 in eee () at testBT2.c:73
#5  0x0804846a in main () at testBT2.c:17

The PC is pointing at the next instruction, accordingly to GDB.
But the kernel tries to restart syscall by means of changing PC to PC-4
(in case of PowerPC and to some other value for x86)
and it does it's change to PC after the user continues execution of
program in GDB with "cont" or "si" command.

The issue is that if user changed PC at this point or uses "call
<func_name>" GDB command, the both changes to PC
are added (as kernel uses PC relative change i.e. PC - 4), and the
program continues execution at absolutely wrong place.

The issue may be gracefully observed if breakpoint is set just before
<func_name> and then PC is changed to the <func_name> address.
In such case the breakpoint is hit while it must not be.

#include <stdio.h>
#include <stdlib.h>

void qqq();
void www();
void eee();

void * xrealloc(void*, int);

int main(void)
{
        eee();
    return EXIT_SUCCESS;

}

void qqq() {
    void *a[256];
    size_t i, n;

    for (i = 0; i < 256; i++)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i] = malloc(n);
    }
    for (i = 256; i > 0; i--)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i - 1] = xrealloc(a[i - 1], n);
    }
    sleep(1);
    for (i = 0; i < 256; i += 2)
        free(a[i]);
    for (i = 256; i > 0; i -= 2)
        free(a[i - 1]);
    sleep(1);

}

void www() {
    void *a[256];
    size_t i, n;

    for (i = 0; i < 256; i++)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i] = malloc(n);
    }
    for (i = 256; i > 0; i--)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i - 1] = realloc(a[i - 1], n);
    }
    sleep(1);
    for (i = 0; i < 256; i += 2)
        free(a[i]);
    for (i = 256; i > 0; i -= 2)
        free(a[i - 1]);
    sleep(1);

}

void eee() {

        while (1) {
                qqq();

                www();

        }

}

void * xrealloc(void* addr, int n) {
        return realloc(addr, n);

}

_______________________________________________
bug-gdb mailing list
bug-...@...
http://lists.gnu.org/mailman/listinfo/bug-gdb

This signal ctrl-c will not really send to inferior.

(gdb) help info handle

On Oct 31, 12:10 am, Alexandre Rusev aru...@... wrote:

Hi.

When the program at ht end of message debugged under GDB is stopped with
Ctrl+C
it's usually found in interrupted system call. (The same result is
observed for x86 and PPC with kernels 2.6.18 and 2.6.28)

(gdb) where
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7f36ad0 in nanosleep () from /lib/libc.so.6
#2  0xb7f3690e in sleep () from /lib/libc.so.6
#3  0x08048600 in qqq () at testBT2.c:45
#4  0x080487a5 in eee () at testBT2.c:73
#5  0x0804846a in main () at testBT2.c:17

The PC is pointing at the next instruction, accordingly to GDB.
But the kernel tries to restart syscall by means of changing PC to PC-4
(in case of PowerPC and to some other value for x86)
and it does it's change to PC after the user continues execution of
program in GDB with "cont" or "si" command.

The issue is that if user changed PC at this point or uses "call
<func_name>" GDB command, the both changes to PC
are added (as kernel uses PC relative change i.e. PC - 4), and the
program continues execution at absolutely wrong place.

The issue may be gracefully observed if breakpoint is set just before
<func_name> and then PC is changed to the <func_name> address.
In such case the breakpoint is hit while it must not be.

#include <stdio.h>
#include <stdlib.h>

void qqq();
void www();
void eee();

void * xrealloc(void*, int);

int main(void)
{
        eee();
    return EXIT_SUCCESS;

}

void qqq() {
    void *a[256];
    size_t i, n;

    for (i = 0; i < 256; i++)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i] = malloc(n);
    }
    for (i = 256; i > 0; i--)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i - 1] = xrealloc(a[i - 1], n);
    }
    sleep(1);
    for (i = 0; i < 256; i += 2)
        free(a[i]);
    for (i = 256; i > 0; i -= 2)
        free(a[i - 1]);
    sleep(1);

}

void www() {
    void *a[256];
    size_t i, n;

    for (i = 0; i < 256; i++)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i] = malloc(n);
    }
    for (i = 256; i > 0; i--)
    {
        n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
        a[i - 1] = realloc(a[i - 1], n);
    }
    sleep(1);
    for (i = 0; i < 256; i += 2)
        free(a[i]);
    for (i = 256; i > 0; i -= 2)
        free(a[i - 1]);
    sleep(1);

}

void eee() {

        while (1) {
                qqq();

                www();

        }

}

void * xrealloc(void* addr, int n) {
        return realloc(addr, n);

}

_______________________________________________
bug-gdb mailing list
bug-gdb@...
http://lists.gnu.org/mailman/listinfo/bug-gdb

Nabble - Gnu - gdb

"display" bug

Re: m4 changequote bug

Re: Problem of GDB interaction with interrupted system calls

Re: Problem of GDB interaction with interrupted system calls

Re: Problem of GDB interaction with interrupted system calls

GDB debugging for a big c language project.

Re: Problem of GDB interaction with interrupted system calls

Re: Problem of GDB interaction with interrupted system calls

Re: GDB 7's process record/replay & BDW-GC

Problem of GDB interaction with interrupted system calls

RE: [Gc] Re: GDB 7's process record/replay & BDW-GC

RE: [Gc] GDB 7's process record/replay & BDW-GC

Re: How does one get static procedure names?

Re: How does one get static procedure names?

Re: How does one get static procedure names?

Re: How does one get static procedure names?

Re: How does one get static procedure names?

Re: How does one get static procedure names?

Re: How does one get static procedure names?

How does one get static procedure names?

have gdb go until SIGSEGV including at the start/end?

Cygwin gdb 7.0 build configure error

GDB's BUG

Reverse debugging questions

Re: How to get gdb to run continuously

How to get gdb to run continuously

GDB RSP protocol question

Breaking execution after continue command

GNU gdb 6.2.1 BUG on NetBSD

conditional watchpoint

Re: gdb says that "disassemble /m" is not a valid command

Re: gdb says that "disassemble /m" is not a valid command

Re: gdb says that "disassemble /m" is not a valid command

gdb says that "disassemble /m" is not a valid command