| Jie Jiang,
Can you also check that the values of 'type' and 'loc' that are used in the asprintf() statement are ok? 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.
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.
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 |
