🚀 go-pugleaf

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>