[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ptp-dev] RE: About setting breakpoints in Fortran program
|
Greg,
Please see my response in the following text.
Any idea?
Jie
> From: ptp-dev-request@xxxxxxxxxxx
> Subject: ptp-dev Digest, Vol 26, Issue 8
> To: ptp-dev@xxxxxxxxxxx
> Date: Mon, 28 May 2007 12:00:03 -0400
>
> Send ptp-dev mailing list submissions to
> ptp-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> or, via email, send a message with subject or body 'help' to
> ptp-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> ptp-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ptp-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: About setting breakpoints in Fortran program (Greg Watson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 28 May 2007 07:44:27 -0600
> From: Greg Watson <g.watson@xxxxxxxxxxxx>
> Subject: Re: [ptp-dev] About setting breakpoints in Fortran program
> To: Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> Message-ID: <C27194CF-660F-41A2-9BE2-E2BF36052008@xxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Jie Jiang,
>
> Can you also check that the values of 'type' and 'loc' that are used
> in the asprintf() statement are ok?
The values of 'type' and 'loc' is ok.
See the following gdb outputs:
(gdb) p type
$1 = 0x600000000001bdf0 "B:627265616B706F696E7400"
(gdb) p loc
$2 = 0x600000000001b2c0 "7:6D61696E2E6600 7:70623264736E00 13:30783430303030303030303030303463643000 36"
(gdb) whatis type
type = char *
(gdb) whatis loc
type = char *
The fact that it's crashing in
> free(), though, is not a good sign. This may be indicative of memory
> corruption elsewhere. Are you able to set a line breakpoint in a C
> program successfully? Or is this problem common to both C and Fortran.
>
I have tested several C programs and everything goes well.
Perhaps this problem is unique to Fortran program.
> Another thing you could check is the output from '-break-insert'
> command. Using a Fortran program (does not need to be MPI) compiled
> with ifort, start gdb in MI mode:
>
> gdb -i mi program
>
> Then set a line breakpoint using the command '-break-insert
> 42' (substitute a correct line number for 42). You could then do the
> same thing with a program compiled with gcc and check that the output
> formats are identical.
When setting line breakpoints for a Fortran program compiled by ifort 9.1 and a C program compiled by gcc,
The gdb-mi outputs are identical.
gdb-mi outputs for the Fortran program:
(gdb)
-break-insert test.f:68
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x4000000000002b81",func="test",file="../test.f",line="68",times="0"}
gdb-mi outputs for the C program:
(gdb)
-break-insert main.c:50
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x4000000000000cc1",func="read_data",file="main.c",line="50",times="0"}
From above, we can see that the gdb-mi outputs both have the same components.
However, the gdb outpus of setting the first tempory breakpoint on "main" entry for C and Fortran program are different.
Fortran program:
(gdb)
-break-insert -t main
^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x4000000000002a42",at="<main+194>",times="0"}
(gdb)
-break-insert -t MAIN__
^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x4000000000002b52",func="test",file="../test.f",line="3",times="0"}
C program:
(gdb)
-break-insert -t main
^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x4000000000000f72",func="main",file="main.c",line="86",times="0"}
Is it possible that it is this difference that cause the memory crash?
>
> Greg
>
>
> On May 27, 2007, at 4:17 AM, jiangyangtz wrote:
>
> > Hi all,
> >
> > Recently I'm working on porting the ptp debugger to support
> > Fortran 77 program. Currently, we have managed to extend the AIF
> > structure to make sdmsvr support the premitive data types of
> > Fortran 77. However, when setting line breakpoints in the F77
> > program source code, something strange occurs.
> > After the initial debug session has been set up, the sdmsvr
> > receives the first MI command from UI and set the first function
> > breakpoint on the entry point of the program, using the MI command
> > "-break-insert -t main". As the "main" symbol is added by the
> > compiler, not in the source code, so we have to issue the "step
> > into" command in the UI and then the execution control of the
> > target program enters into the first line of its statement and the
> > associated source code will be displayed in the UI view. All things
> > work well by now.
> >
> > But when I try to set a line breakpoint in the source code file,
> > the sdmsvr will crashed due to a SIGSEGV signal. I traced the core
> > dump file generated by the sdmsvr and get the following outputs:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x2000000000173510 in malloc_consolidate () from /lib/tls/libc.so.6.1
> > (gdb) bt
> > #0 0x2000000000173510 in malloc_consolidate () from /lib/tls/
> > libc.so.6.1
> > #1 0x2000000000175f20 in _int_free () from /lib/tls/libc.so.6.1
> > #2 0x20000000001766f0 in free () from /lib/tls/libc.so.6.1
> > #3 0x2000000000165650 in vasprintf () from /lib/tls/libc.so.6.1
> > #4 0x2000000000139070 in asprintf () from /lib/tls/libc.so.6.1
> > #5 0x4000000000018c70 in dbg_breakpoint_to_str
> > (bp=0x600000000001aa00, result=0x60000fffffffa8e8) at src/utils/
> > event.c:61
> > #6 0x4000000000019fd0 in DbgEventToStr (e=0x6000000000018040,
> > result=0x60000fffffffa938) at src/utils/event.c:269
> > #7 0x4000000000003ce0 in event_callback (e=0x6000000000018040,
> > data="" at src/server/server.c:84
> > #8 0x400000000000bfd0 in GDBMIProgress () at src/server/
> > gdbmi_backend.c:887
> > #9 0x40000000 00005330 in svr_progress (db=0x600000000000d860) at
> > src/server/server_cmds.c:177
> > #10 0x4000000000004be0 in server (sockfd=4,
> > dbgr=0x600000000000d860) at src/server/server.c:301
> > #11 0x4000000000003990 in main (argc=7, argv=0x60000fffffffaf08) at
> > src/server/svr_startup.c:300
> >
> > when moving along the stack upward,
> >
> > (gdb) up
> > #1 0x2000000000175f20 in _int_free () from /lib/tls/libc.so.6.1
> > (gdb) up
> > #2 0x20000000001766f0 in free () from /lib/tls/libc.so.6.1
> > (gdb) up
> > #3 0x2000000000165650 in vasprintf () from /lib/tls/libc.so.6.1
> > (gdb) up
> > #4 0x2000000000139070 in asprintf () from /lib/tls/libc.so.6.1
> > (gdb) up
> > #5 0x4000000000018c70 in dbg_breakpoint_to_str
> > (bp=0x600000000001aa00, result=0x60000fffffffa8e8) at src/utils/
> > event.c:61
> > 61 asprintf(result, "%d %d %d %d %s %s %d", bp->id, bp-
> > >ignore, bp->special, bp->deleted, type, loc, bp->hits);
> > (gdb) up
> > #6 0x4000000000019fd0 in DbgEventToStr (e=0x6000000000018040,
> > result=0x60000fffffffa938) at src/utils/event.c:269
> > 269 dbg_breakpoint_to_str(e->dbg_event_u.bpset_
> > event.bp, &str);
> > (gdb) p *e
> > $1 = {event = 104, procs = 0x0, dbg_event_u = {num_servers = 1,
> > bpset_event = {bpid = 1, bp = 0x600000000001aa00}, list = 0x1,
> > type_desc = 0x1 <Address 0x1 out of bounds>, data_event =
> > {type_desc = 0x1 <Address 0x1 out of bounds>,
> > data = "" exit_event = {reason = 1, ev_u =
> > {exit_status = 109056, sig = 0x600000000001aa00}},
> > error_event = {error_code = 1, error_msg = 0x600000000001aa00
> > "\002"}, suspend_event = {reason = 1, ev_u = {bpid = 109056,
> > sig = 0x600000000001aa00}, thread_id = 0, frame = 0x0,
> > changed_vars = 0x0}, stack_depth = 1, meminfo = 0x1,
> > threads_event = {list = 0x1, thread_id = 109056},
> > thread_select_event = {frame = 0x1, thread_id = 109056}}}
> > (gdb) down
> > #5 0x4000000000018c70 in dbg_breakpoint_to_str
> > (bp=0x600000000001aa00, result=0x600 00fffffffa8e8) at src/utils/
> > event.c:61
> > 61 asprintf(result, "%d %d %d %d %s %s %d", bp->id, bp-
> > >ignore, bp->special, bp->deleted, type, loc, bp->hits);
> > (gdb) p bp
> > $2 = (breakpoint *) 0x600000000001aa00
> > (gdb) p *bp
> > $3 = {id = 2, ignore = 0, special = 0, deleted = 0, type =
> > 0x60000000000183c0 "breakpoint", loc = {
> > file = 0x600000000001bc30 "main.f", func = 0x600000000001bbe0
> > "pb2dsn",
> > addr = 0x60000000000183e0 "0x4", '0' <repeats 11 times>,
> > "4ba1", line = 27}, hits = 0}
> >
> >
> > >From the above context, the SIGSEGV signal occured during the
> > memory allocation in the process of handling "DBGEV_BPSET" event.
> > I have repeated the test many times and always get the same
> > results. Also, when running sdmsvr under the control of gdb, we get
> > the same results.
> > I have examined the source code of sdmsvr carefully and have no
> > idea what reason will cause this effect, since everything goes well
> > for a C program!
> >
> > In addition, I found a interesting, but also confusing phoenominon,
> > when firstly setting a function breakpoint instead of line
> > breakpoint, sdmsvr will work smoothly.
> >
> > By the way, my platform is IA64 Itanium +Suse Linux 10.0, and the
> > sdmsvr is compiled by gcc, while the target Fortran program is
> > compiled by ifort 9.1.
> >
> > I have been confused by this problem several days and am anxious to
> > solve it. Any suggestion is appreciated.
> >
> > Best regards,
> > Jie Jiang
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 通过 Live.com 查看资讯ã€å¨±ä¹ä¿¡æ¯å’Œæ‚¨å…³å¿ƒçš„其他信
> > æ¯ï¼ ç«‹å³å°è¯•ï¼
> > _______________________________________________
> > ptp-dev mailing list
> > ptp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: https://dev.eclipse.org/mailman/listinfo/ptp-dev/attachments/20070528/37a83774/attachment.html
>
> ------------------------------
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
>
> End of ptp-dev Digest, Vol 26, Issue 8
> **************************************
使用下一代的 MSN Messenger。
立即尝试！
