🚀 go-pugleaf

J. Cone writes:
 > Dear Sir/Madam,
 > 
 > Please tell me whether the following is a known problem, or else tell me 
 > where to stick printf's into the gdb code to try to understand it.
 > 
 > 
 > My machine: HP-UX hp5 B.11.00 A 9000/785 2002388384 two-user license
 >     - this is running 64-bit hpux, but I am debugging 32-bit som programs
 > 
 > Details of gdb:
 > $ gdb
 > GNU gdb 5.1
 > Copyright 2001 Free Software Foundation, Inc.
 > GDB is free software, covered by the GNU General Public License, and you are
 > welcome to change it and/or distribute copies of it under certain conditions.
 > Type "show copying" to see the conditions.
 > There is absolutely no warranty for GDB.  Type "show warranty" for details.
 > This GDB was configured as "hppa2.0-hp-hpux11.00".
 > 
 > Built with GCC 3.0.3.
 > 
 > The README says that it doesn't build.  I disagree; it built for hppa2.0 
 > (som binaries) and hppa2.0w (64-bit elf binaries).
 > 
 > It does post-mortem debugging apparently correctly, although it may be 
 > mis-interpreting the location of the vtable pointers in C++.
 > 
 > When I try to run a program from within it, I get to a state like this:
 > 
 > # ps -ef | fgrep smsM
 > smf_oper  8391     1  0 18:12:28 pts/0     0:00 ./smsMaster
 > smf_oper  8731  8701  0 18:14:13 pts/ta    0:00 gdb bin/smsMaster.jcone
 > smf_oper  8701  3418  0 18:14:11 pts/ta    0:00 gdb bin/smsMaster.jcone
 >      root  9470  9012  0 18:14:24 pts/tb    0:00 fgrep smsM
 > # ps -lp 8731
 >    F S        UID   PID  PPID  C PRI 
 > NI             ADDR   SZ            WCHAN TTY       TIME COMD
 >   11 R        102  8731  8701  0 152 
 > 20         422c3700  900                - pts/ta    0:00 gdb
 > # ps -lp 8701
 >    F S        UID   PID  PPID  C PRI 
 > NI             ADDR   SZ            WCHAN TTY       TIME COMD
 >    1 S        102  8701  3418  0 152 
 > 20         422c3700  900          2000fa8 pts/ta    0:00 gdb
 > 
 > The gdb hangs forever having produced:
 > 
 > (gdb) run
 > Starting program: /volA/IN/service_packages/SMS/bin/smsMaster.jcone
 > 
 > and only kill -9 will kill the child, after which the parent (the original 
 > gdb) will bus-error.
 > 
 > 
 > I can't get a debugger onto the child, because it's already being debugged.
 > 
 > I can't get a debugger onto the parent.  When I try, I get:
 > 
 > Attaching to program: /opt/gcc-3.0.3/bin/gdb, process 11446
 > ttrace attach: Lockf deadlock detection.
 > 
 > the manual page for which says someone has vfork'ed and not yet exec'd.
 > 
 > Sincerely stuck,
 > James Cone.
 > 
 > 


Yes, known problem, vfork seems to not work properly on such platform.
Try this patch (of course, adapt it to hpux1100.mh or whatever
makefile fragment you end up using).

Elena


Index: hpux1020.mh
===================================================================
RCS file: /cvs/uberbaum/gdb/config/pa/hpux1020.mh,v
retrieving revision 1.3
diff -u -r1.3 hpux1020.mh
--- hpux1020.mh 2002/01/18 04:51:05     1.3
+++ hpux1020.mh 2002/01/21 19:01:06
@@ -1,10 +1,10 @@
 # Host: Hewlett-Packard PA-RISC machine, running HPUX 10.20
 
-MH_CFLAGS = -D__HP_CURSES
+MH_CFLAGS = -D__HP_CURSES -Dvfork=fork


 > 
 > _______________________________________________
 > Bug-gdb mailing list
 > Bug-gdb@gnu.org
 > http://mail.gnu.org/mailman/listinfo/bug-gdb

Hello Elena,

Thank you.  It no longer hangs.

My symptoms are now a bus error either running a program in the debugger, 
or attaching the debugger.
Using an older debugger (which goes but can't read the symbols in my 
GCC-3.0.3 program :-(  ),
the top few lines of the back-trace are.

Program received signal SIGBUS, Bus error.
0x92de8 in add_thread (ptid={pid = -1774190241, lwp = 402653185,
       tid = 1426915583}) at thread.c:125
125     {
(top-gdb) bt
#0  0x92de8 in add_thread (ptid={pid = -1774190241, lwp = 402653185,
       tid = 1426915583}) at thread.c:125
#1  0xa1690 in child_acknowledge_created_inferior (pid=29475)
     at infttrace.c:3126
#2  0x9f150 in ptrace_him (pid=29475) at inftarg.c:444
#3  0xed154 in fork_inferior (exec_file_arg=0x7323 "\226@\001_\030",
     allargs=0x400390e0 "", env=0x40039100,
     traceme_fun=0x40016172 <_exit_dummy_decl+5330>,
     init_trace_fun=0x4001617a <_exit_dummy_decl+5338>,
     pre_trace_fun=0x40016182 <_exit_dummy_decl+5346>, shell_file_arg=0x0)
     at fork-child.c:363

ptid is clearly insane, and looking down the stack, there seems to be a 
type conflict
where the caller's data is sane but a completely different shape.

(top-gdb) up
#1  0xa1690 in child_acknowledge_created_inferior (pid=29475)
     at infttrace.c:3126
3126      add_thread (pid);             /* in thread.c */
(top-gdb) print pid
$2 = 29475
(top-gdb) shell ps -ef | fgrep gdb
smf_oper 29416  3418  0 19:17:33 pts/ta    0:00 gdb2 bin/smsMaster.jcone
     root 29456 29177  1 19:18:22 pts/tb    0:01 /opt/gdb/bin/gdb ./gdb 29416
smf_oper 29475 29416  0 19:18:42 pts/ta    0:00 gdb2 bin/smsMaster.jcone
     root 29497 29456  2 19:19:22 pts/tb    0:00 ksh -c ps -ef | fgrep gdb
(top-gdb)

If you know this problem too, I'd love a solution, but it's now 7pm local 
time, so I'm running away, so it's not urgent.

Thanks for your help,
James.

At 00:42 8/02/2002 -0500, Elena Zannoni wrote:
>J. Cone writes:
<snip>
  > The gdb hangs forever having produced:
>  >
>  > (gdb) run
>  > Starting program: /volA/IN/service_packages/SMS/bin/smsMaster.jcone
>
>Yes, known problem, vfork seems to not work properly on such platform.
>Try this patch (of course, adapt it to hpux1100.mh or whatever
>makefile fragment you end up using).
>
>Elena
<snip>

Hello Elena et al,

I was distracted from leaving and have cobbled together something which:
   - doesn't dump core
   - works well enough for my substantive problem

In infttrace.c:
29:   #include "gdbthread.h"
    - it defines add_thread
3127:  add_thread (pid_to_ptid(pid));
    - replaces the existing call
4777:  add_thread (ptid_build(pid, 0, tid));
    - replaces the existing call
    - the person who really understands this should work out how to get the 
lwp_t

Your original makefile advice is still necessary for these changes to help.

Regards,
James Cone.

At 19:23 8/02/2002 +1300, Elena Zannoni , "J. Cone" 
<jcone@eservglobal.co.nz> wrote:
>Hello Elena,
>
>Thank you.  It no longer hangs.
>
>My symptoms are now a bus error either running a program in the debugger, 
>or attaching the debugger.
>Using an older debugger (which goes but can't read the symbols in my 
>GCC-3.0.3 program :-(  ),
>the top few lines of the back-trace are.
>
>Program received signal SIGBUS, Bus error.
>0x92de8 in add_thread (ptid={pid = -1774190241, lwp = 402653185,
>       tid = 1426915583}) at thread.c:125
>125     {
>(top-gdb) bt
>#0  0x92de8 in add_thread (ptid={pid = -1774190241, lwp = 402653185,
>       tid = 1426915583}) at thread.c:125
>#1  0xa1690 in child_acknowledge_created_inferior (pid=29475)
>     at infttrace.c:3126
>#2  0x9f150 in ptrace_him (pid=29475) at inftarg.c:444
>#3  0xed154 in fork_inferior (exec_file_arg=0x7323 "\226@\001_\030",
>     allargs=0x400390e0 "", env=0x40039100,
>     traceme_fun=0x40016172 <_exit_dummy_decl+5330>,
>     init_trace_fun=0x4001617a <_exit_dummy_decl+5338>,
>     pre_trace_fun=0x40016182 <_exit_dummy_decl+5346>, shell_file_arg=0x0)
>     at fork-child.c:363
>
>ptid is clearly insane, and looking down the stack, there seems to be a 
>type conflict
>where the caller's data is sane but a completely different shape.
>
>(top-gdb) up
>#1  0xa1690 in child_acknowledge_created_inferior (pid=29475)
>     at infttrace.c:3126
>3126      add_thread (pid);             /* in thread.c */
>(top-gdb) print pid
>$2 = 29475
>(top-gdb) shell ps -ef | fgrep gdb
>smf_oper 29416  3418  0 19:17:33 pts/ta    0:00 gdb2 bin/smsMaster.jcone
>     root 29456 29177  1 19:18:22 pts/tb    0:01 /opt/gdb/bin/gdb ./gdb 29416
>smf_oper 29475 29416  0 19:18:42 pts/ta    0:00 gdb2 bin/smsMaster.jcone
>     root 29497 29456  2 19:19:22 pts/tb    0:00 ksh -c ps -ef | fgrep gdb
>(top-gdb)
>
>If you know this problem too, I'd love a solution, but it's now 7pm local 
>time, so I'm running away, so it's not urgent.
>
>Thanks for your help,
>James.
>
>At 00:42 8/02/2002 -0500, Elena Zannoni wrote:
>>J. Cone writes:
><snip>
>  > The gdb hangs forever having produced:
>>  >
>>  > (gdb) run
>>  > Starting program: /volA/IN/service_packages/SMS/bin/smsMaster.jcone
>>
>>Yes, known problem, vfork seems to not work properly on such platform.
>>Try this patch (of course, adapt it to hpux1100.mh or whatever
>>makefile fragment you end up using).
>>
>>Elena
><snip>