This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] New thread testcase.


Manoj,

It sounds from your eplanation like the "step" part of your test
is not required, since your bug shows up without it.  I explained
in my previous msg why I was concerned about that test.  What
would you think of removing the step?

Michael

Manoj Iyer wrote:
oh! sorry abt that... got confused btwn 'bugs'...

The kernel bug was causing gdb to fail when passing a 32bit address to the
kernel.  this was causing 32 bit gdb to fail in linux_test_for_tracefork()
by always returning second_pid = 0 in the PTRACE_GETEVENTMSG call.

this resulted in linux_enable_event_reporting() not setting the PTRACE
fork options for the pid and then the thread never received a SIGSTOP.

John Engel, kernel developer, debugged and fixed this problem in the
kernel after we reported this GDB problem to him...

So, when you debug a multi-threaded app with 32bit GDB on a PPC64 system,
and you set a break point at the thread function and tried to step, you
get the message "reading register pc (#64): No such process." for example:

Breakpoint 1, main (argc=1, argv=0xffffe464) at tbug.c:31
31        for (n = 0; n < N; ++n)
(gdb) cont
Continuing.
[New Thread 1078217504 (LWP 26708)]
tf(0): begin
[New Thread 1082411808 (LWP 26709)]
after create
tf(1): begin
tf(0): end
[Thread 1078217504 (LWP 26708) exited]
tf(1): end
[Thread 1082411808 (LWP 26709) exited]
after join

Program exited normally.
(gdb) clear main
Deleted breakpoint 1
(gdb) break tf
Breakpoint 2 at 0x10000594: file tbug.c, line 15.
(gdb) run
Starting program: /home/public/test-tools/gdb/tbug
[Thread debugging using libthread_db enabled]
[New Thread 1074020384 (LWP 26710)]
reading register pc (#64): No such process.
(gdb) cont
Continuing.
reading register pc (#64): No such process.

Thanks
----- ----
Manoj Iyer
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cognito ergo sum +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Tue, 10 Aug 2004, Andrew Cagney wrote:


Manoj,

You've got me curious.  Do any of the existing tests exercise this bug
(manythreads.exp comes to mind)?   Oh, and what is the bug? :-)



This is a generic kernel bug (in ptrace() )that causes ptrace to fail on
Power 64 systems.  Please look at PR#1712 for details.

Unfortunatly 1712 doesn't answer my question. What is the bug? What causes ptrace to fail?

Andrew








Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]