Bug 445063 - multi-process debug error
Summary: multi-process debug error
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf-gdb (show other bugs)
Version: 8.4.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-25 05:41 EDT by jia kai CLA
Modified: 2020-09-04 15:26 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jia kai CLA 2014-09-25 05:41:53 EDT
my setting:
set detach-on-fork off
set follow-fork-mode child

first I doesn't set any breakpoint, when I press F11 to start debug,
after parent called fork() ,the parent should be in hang-up state,
the child should be in running state, and I want to continue the parent,
but the Resume button is disabled and Suspend is enable,I think that is
wrong.
Comment 1 Marc Khouzam CLA 2014-09-28 20:34:43 EDT
Could you provide a simple test program that we can reproduce the problem with?
Comment 2 jia kai CLA 2014-09-28 22:00:35 EDT
(In reply to Marc Khouzam from comment #1)
> Could you provide a simple test program that we can reproduce the problem
> with?

int
fork_main (int argc, char ** argv)
{
    int rc = fork();
    if (rc < 0) exit(1);
    else if (rc == 0) {
        for (;;) {
            puts("I am child");
            sleep(1);
        }
    } else {
        for (;;) {
            puts("I am parent");
            sleep(1);
        }
    }
    return 0;
}

BTW, if I set breakpoint or not, the problem both exists.
the parent kernel stack:
[<ffffffff810d50b7>] utrace_stop+0xf7/0x1e0
[<ffffffff810d51e7>] finish_resume_report+0x47/0x100
[<ffffffff810d532b>] utrace_resume+0x8b/0x110
[<ffffffff8100aaa0>] do_notify_resume+0xb0/0xc0
[<ffffffff8100b341>] int_signal+0x12/0x17
[<ffffffffffffffff>] 0xffffffffffffffff

the child kernel stack:
[<ffffffff810a02a4>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a03ce>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
Comment 3 jia kai CLA 2014-09-28 22:05:36 EDT
# gdb -v
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Comment 4 Marc Khouzam CLA 2014-09-29 09:37:49 EDT
(In reply to jia kai from comment #3)
> # gdb -v
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2)
> Copyright (C) 2010 Free Software Foundation, Inc.

That is a really old GDB where multi-process was very new.  Many things were fixed since then.

I recommend trying a more recent version to see if the behaviour is better.
Comment 5 jia kai CLA 2014-09-29 23:09:27 EDT
I tried a new GDB (built from source):
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

the problem still exists.
And another problem:

1.add a breakpoint before debug;
2.start debugging, and the program suspended at the breakpoint;
3.delete the breakpoint and continue the program;
4.add the breakpoint(program is running now) at the same position, and after
 a while the program should be reached here again, but the breakpoint cannot suspend the program now.

Thanks.
Comment 6 Marc Khouzam CLA 2014-09-30 15:19:54 EDT
Using the test program I was not able to reproduce the problem.  I get both child and parent being debugged.

I use non-stop mode, and I copy pasted

set detach-on-fork off
set follow-fork-mode child

into the gdb console when the program stopped at main.