* About the gdb prec save/restore reverse exec behavior error (gcore error)
@ 2009-10-31 17:41 Hui Zhu
[not found] ` <4AEC74B8.9090908@vmware.com>
0 siblings, 1 reply; 5+ messages in thread
From: Hui Zhu @ 2009-10-31 17:41 UTC (permalink / raw)
To: gdb; +Cc: Michael Snyder
Hi guys,
I found that prec save/restore reverse exec behavior error. For example:
gdb ./a.out ./gdb_record.8810
Reading symbols from /home/teawater/gdb/a.out...done.
[New Thread 8810]
Core was generated by `/home/teawater/gdb/a.out'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 main () at 1.c:20
20 int b = 0;
(gdb) record
Restored records from core file /home/teawater/gdb/./gdb_record.8810.
#0 main () at 1.c:20
20 int b = 0;
(gdb) n
21 int c = 1;
(gdb)
24 printf ("a = %d b = %d c = %d\n", a, b, c);
(gdb)
25 b = cool ();
(gdb) rn
No more reverse-execution history.
main () at 1.c:20
20 int b = 0;
The reason is:
(gdb) rn
infrun: stop_pc = 0x7ffff7abbec1
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x0 #address error
infrun: status->kind = no-history
infrun: infwait_normal_state
No more reverse-execution history.
infrun: stop_stepping
main () at 1.c:20
20 int b = 0;
The address is not right because:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddea90 0x00007ffff7df7334 Yes (*) /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.
Without the solib that have printf, gdb cannot find the debug message.of printf.
But current gdb way cannot get the solib message.
For example:
gdb ./a.out ./gdb_record.8810
[New Thread 8810]
Core was generated by `/home/teawater/gdb/a.out'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 main () at 1.c:20
20 int b = 0;
(gdb) record
Restored records from core file /home/teawater/gdb/./gdb_record.8810.
#0 main () at 1.c:20
20 int b = 0;
(gdb) set solib-search-path
(gdb)
Not any output is because gdb cannot get any message of solib.
To get solib message need .dynamic section in
"solib-svr4.c:scan_dyntag", but this section's flags is:
[21] .dynamic DYNAMIC 0000000000600e40 00000e40
00000000000001a0 0000000000000010 WA 6 0 8
It just alloc when inferior exec. And gcore didn't save the memory of .dynamic.
So when prec restore (inferior didn't exec) cannot get the the solib message.
I found that kernel coredump have the .dynamic message:
./a.out
a.out: 2.c:5: main: Assertion `0' failed.
(core dumped)
gdb ./a.out core
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007fcc52666230 0x00007fcc5276b0e8 Yes (*) /lib/libc.so.6
0x00007fcc529baa90 0x00007fcc529d3334 Yes (*) /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.
Core file of gcore didn't make gdb auto load solib because in
"solib-svr4.c:scan_dyntag" get value from .dynamic section.
635 dyn_ptr = extract_typed_address (ptr_buf, ptr_type);
(gdb) x ptr_addr
0x600ed8
(gdb) p ptr_buf
$20 = "\000\000\000\000\000\000\000"
Then gdb
But when gcore didn't save the value from this section in "gcore_copy_callback":
/* Read-only sections are marked; we don't have to copy their contents. */
if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0)
return;
cat /proc/7122/maps
00400000-00401000 r-xp 00000000 08:06 4980746
/home/teawater/gdb/a.out
00600000-00601000 r--p 00000000 08:06 4980746
/home/teawater/gdb/a.out
00601000-00602000 rw-p 00001000 08:06 4980746
/home/teawater/gdb/a.out
7ffff7a6c000-7ffff7bd4000 r-xp 00000000 08:06 3022954
/lib/libc-2.9.so
7ffff7bd4000-7ffff7dd4000 ---p 00168000 08:06 3022954
/lib/libc-2.9.so
7ffff7dd4000-7ffff7dd8000 r--p 00168000 08:06 3022954
/lib/libc-2.9.so
7ffff7dd8000-7ffff7dd9000 rw-p 0016c000 08:06 3022954
/lib/libc-2.9.so
7ffff7dd9000-7ffff7dde000 rw-p 7ffff7dd9000 00:00 0
7ffff7dde000-7ffff7dfe000 r-xp 00000000 08:06 3022858
/lib/ld-2.9.so
7ffff7fd5000-7ffff7fd7000 rw-p 7ffff7fd5000 00:00 0
7ffff7ff9000-7ffff7ffc000 rw-p 7ffff7ff9000 00:00 0
7ffff7ffc000-7ffff7ffd000 r-xp 7ffff7ffc000 00:00 0 [vdso]
7ffff7ffd000-7ffff7ffe000 r--p 0001f000 08:06 3022858
/lib/ld-2.9.so
7ffff7ffe000-7ffff7fff000 rw-p 00020000 08:06 3022858
/lib/ld-2.9.so
7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
I think this is the root cause of this issue. Sorry guys, I use a
long mail to show it.
Do you have some comment with it?
Thanks,
Hui
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <4AEC74B8.9090908@vmware.com>]
* Re: About the gdb prec save/restore reverse exec behavior error (gcore error) [not found] ` <4AEC74B8.9090908@vmware.com> @ 2009-11-04 6:56 ` Hui Zhu 2009-11-04 18:29 ` Michael Snyder 0 siblings, 1 reply; 5+ messages in thread From: Hui Zhu @ 2009-11-04 6:56 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb [-- Attachment #1: Type: text/plain, Size: 5984 bytes --] Hi Michael, I make a patch to fix it. I try in i386-ubuntu. It is OK now. Please help me review it. Thanks, Hui 2009-11-04 Hui Zhu <teawater@gmail.com> * gcore.c (gcore_copy_callback): Remove bfd_get_section_flags check. --- gcore.c | 4 ---- 1 file changed, 4 deletions(-) --- a/gcore.c +++ b/gcore.c @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection struct cleanup *old_chain = NULL; void *memhunk; - /* Read-only sections are marked; we don't have to copy their contents. */ - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) - return; - /* Only interested in "load" sections. */ if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) return; On Sun, Nov 1, 2009 at 01:32, Michael Snyder <msnyder@vmware.com> wrote: > Hi Hui, > > Nice job of diagnostics. You feel up to fixing it? > This would be a nice fix for gcore as well. > > Michael > > Hui Zhu wrote: >> >> Hi guys, >> >> I found that prec save/restore reverse exec behavior error. For example: >> gdb ./a.out ./gdb_record.8810 >> Reading symbols from /home/teawater/gdb/a.out...done. >> [New Thread 8810] >> Core was generated by `/home/teawater/gdb/a.out'. >> Program terminated with signal 5, Trace/breakpoint trap. >> #0 main () at 1.c:20 >> 20 int b = 0; >> (gdb) record >> Restored records from core file /home/teawater/gdb/./gdb_record.8810. >> #0 main () at 1.c:20 >> 20 int b = 0; >> (gdb) n >> 21 int c = 1; >> (gdb) >> 24 printf ("a = %d b = %d c = %d\n", a, b, c); >> (gdb) >> 25 b = cool (); >> (gdb) rn >> >> No more reverse-execution history. >> main () at 1.c:20 >> 20 int b = 0; >> >> The reason is: >> (gdb) rn >> infrun: stop_pc = 0x7ffff7abbec1 >> infrun: stepped into subroutine >> infrun: inserting step-resume breakpoint at 0x0 #address error >> infrun: status->kind = no-history >> infrun: infwait_normal_state >> >> No more reverse-execution history. >> infrun: stop_stepping >> main () at 1.c:20 >> 20 int b = 0; >> >> The address is not right because: >> (gdb) info sharedlibrary >> From To Syms Read Shared Object Library >> 0x00007ffff7ddea90 0x00007ffff7df7334 Yes (*) >> /lib64/ld-linux-x86-64.so.2 >> (*): Shared library is missing debugging information. >> >> Without the solib that have printf, gdb cannot find the debug message.of >> printf. >> >> >> But current gdb way cannot get the solib message. >> For example: >> gdb ./a.out ./gdb_record.8810 >> [New Thread 8810] >> Core was generated by `/home/teawater/gdb/a.out'. >> Program terminated with signal 5, Trace/breakpoint trap. >> #0 main () at 1.c:20 >> 20 int b = 0; >> (gdb) record >> Restored records from core file /home/teawater/gdb/./gdb_record.8810. >> #0 main () at 1.c:20 >> 20 int b = 0; >> (gdb) set solib-search-path >> (gdb) >> Not any output is because gdb cannot get any message of solib. >> To get solib message need .dynamic section in >> "solib-svr4.c:scan_dyntag", but this section's flags is: >> [21] .dynamic DYNAMIC 0000000000600e40 00000e40 >> 00000000000001a0 0000000000000010 WA 6 0 8 >> It just alloc when inferior exec. And gcore didn't save the memory of >> .dynamic. >> So when prec restore (inferior didn't exec) cannot get the the solib >> message. >> >> I found that kernel coredump have the .dynamic message: >> ./a.out >> a.out: 2.c:5: main: Assertion `0' failed. >> (core dumped) >> gdb ./a.out core >> (gdb) info sharedlibrary >> From To Syms Read Shared Object Library >> 0x00007fcc52666230 0x00007fcc5276b0e8 Yes (*) /lib/libc.so.6 >> 0x00007fcc529baa90 0x00007fcc529d3334 Yes (*) >> /lib64/ld-linux-x86-64.so.2 >> (*): Shared library is missing debugging information. >> >> >> Core file of gcore didn't make gdb auto load solib because in >> "solib-svr4.c:scan_dyntag" get value from .dynamic section. >> 635 dyn_ptr = extract_typed_address (ptr_buf, >> ptr_type); >> (gdb) x ptr_addr >> 0x600ed8 >> (gdb) p ptr_buf >> $20 = "\000\000\000\000\000\000\000" >> Then gdb >> But when gcore didn't save the value from this section in >> "gcore_copy_callback": >> /* Read-only sections are marked; we don't have to copy their contents. >> */ >> if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) >> return; >> cat /proc/7122/maps >> 00400000-00401000 r-xp 00000000 08:06 4980746 >> /home/teawater/gdb/a.out >> 00600000-00601000 r--p 00000000 08:06 4980746 >> /home/teawater/gdb/a.out >> 00601000-00602000 rw-p 00001000 08:06 4980746 >> /home/teawater/gdb/a.out >> 7ffff7a6c000-7ffff7bd4000 r-xp 00000000 08:06 3022954 >> /lib/libc-2.9.so >> 7ffff7bd4000-7ffff7dd4000 ---p 00168000 08:06 3022954 >> /lib/libc-2.9.so >> 7ffff7dd4000-7ffff7dd8000 r--p 00168000 08:06 3022954 >> /lib/libc-2.9.so >> 7ffff7dd8000-7ffff7dd9000 rw-p 0016c000 08:06 3022954 >> /lib/libc-2.9.so >> 7ffff7dd9000-7ffff7dde000 rw-p 7ffff7dd9000 00:00 0 >> 7ffff7dde000-7ffff7dfe000 r-xp 00000000 08:06 3022858 >> /lib/ld-2.9.so >> 7ffff7fd5000-7ffff7fd7000 rw-p 7ffff7fd5000 00:00 0 >> 7ffff7ff9000-7ffff7ffc000 rw-p 7ffff7ff9000 00:00 0 >> 7ffff7ffc000-7ffff7ffd000 r-xp 7ffff7ffc000 00:00 0 >> [vdso] >> 7ffff7ffd000-7ffff7ffe000 r--p 0001f000 08:06 3022858 >> /lib/ld-2.9.so >> 7ffff7ffe000-7ffff7fff000 rw-p 00020000 08:06 3022858 >> /lib/ld-2.9.so >> 7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0 >> [stack] >> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >> [vsyscall] >> >> >> >> I think this is the root cause of this issue. Sorry guys, I use a >> long mail to show it. >> >> Do you have some comment with it? >> >> Thanks, >> Hui > > [-- Attachment #2: fix-gcore-lib.txt --] [-- Type: text/plain, Size: 483 bytes --] --- gcore.c | 4 ---- 1 file changed, 4 deletions(-) --- a/gcore.c +++ b/gcore.c @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection struct cleanup *old_chain = NULL; void *memhunk; - /* Read-only sections are marked; we don't have to copy their contents. */ - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) - return; - /* Only interested in "load" sections. */ if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) return; ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: About the gdb prec save/restore reverse exec behavior error (gcore error) 2009-11-04 6:56 ` Hui Zhu @ 2009-11-04 18:29 ` Michael Snyder 2009-11-05 2:24 ` Hui Zhu 0 siblings, 1 reply; 5+ messages in thread From: Michael Snyder @ 2009-11-04 18:29 UTC (permalink / raw) To: Hui Zhu; +Cc: gdb Hui Zhu wrote: > Hi Michael, > > I make a patch to fix it. I try in i386-ubuntu. It is OK now. > Please help me review it. > > Thanks, > Hui > > 2009-11-04 Hui Zhu <teawater@gmail.com> > > * gcore.c (gcore_copy_callback): Remove bfd_get_section_flags check. > > --- > gcore.c | 4 ---- > 1 file changed, 4 deletions(-) > > --- a/gcore.c > +++ b/gcore.c > @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection > struct cleanup *old_chain = NULL; > void *memhunk; > > - /* Read-only sections are marked; we don't have to copy their contents. */ > - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) > - return; > - > /* Only interested in "load" sections. */ > if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) > return; > No, this is not acceptable. We can't save ALL of the loadable sections, it will make the gcore file much bigger than necessary. Most loadable sections are code, and do not need to be saved. We will need to choose explicitly just the loadable sections that we need to save. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: About the gdb prec save/restore reverse exec behavior error (gcore error) 2009-11-04 18:29 ` Michael Snyder @ 2009-11-05 2:24 ` Hui Zhu 2009-11-05 2:26 ` Hui Zhu 0 siblings, 1 reply; 5+ messages in thread From: Hui Zhu @ 2009-11-05 2:24 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb Faint, I found that issue just cannot reproduce in amd64 ubuntu 9.0.4 and i386 ubuntu 9.0.4. It's gcc is 4.3.3. glibc is 2.9. In amd64 gcc 4.1.2 glibc 2.5 and i386 gcc 4.2.4 glibc 2.7, it cannot be reproduced. I think we need do more work on it and need more people's help. Thanks, Hui On Thu, Nov 5, 2009 at 02:29, Michael Snyder <msnyder@vmware.com> wrote: > Hui Zhu wrote: >> >> Hi Michael, >> >> I make a patch to fix it. I try in i386-ubuntu. It is OK now. >> Please help me review it. >> >> Thanks, >> Hui >> >> 2009-11-04 Hui Zhu <teawater@gmail.com> >> >> * gcore.c (gcore_copy_callback): Remove bfd_get_section_flags >> check. >> >> --- >> gcore.c | 4 ---- >> 1 file changed, 4 deletions(-) >> >> --- a/gcore.c >> +++ b/gcore.c >> @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection >> struct cleanup *old_chain = NULL; >> void *memhunk; >> >> - /* Read-only sections are marked; we don't have to copy their contents. >> */ >> - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) >> - return; >> - >> /* Only interested in "load" sections. */ >> if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) >> return; >> > > No, this is not acceptable. We can't save ALL of the loadable > sections, it will make the gcore file much bigger than necessary. > Most loadable sections are code, and do not need to be saved. > > We will need to choose explicitly just the loadable sections > that we need to save. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: About the gdb prec save/restore reverse exec behavior error (gcore error) 2009-11-05 2:24 ` Hui Zhu @ 2009-11-05 2:26 ` Hui Zhu 0 siblings, 0 replies; 5+ messages in thread From: Hui Zhu @ 2009-11-05 2:26 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb Sorry I make a mistake, please ignore prev mail. The right mail is: Faint, I found that issue just can reproduce in amd64 ubuntu 9.0.4 and i386 ubuntu 9.0.4. It's gcc is 4.3.3. glibc is 2.9. In amd64 gcc 4.1.2 glibc 2.5 and i386 gcc 4.2.4 glibc 2.7, it cannot be reproduced. I think we need do more work on it and need more people's help. Thanks, Hui On Thu, Nov 5, 2009 at 10:24, Hui Zhu <teawater@gmail.com> wrote: > Faint, I found that issue just cannot reproduce in amd64 ubuntu 9.0.4 > and i386 ubuntu 9.0.4. > > It's gcc is 4.3.3. glibc is 2.9. > > In amd64 gcc 4.1.2 glibc 2.5 and i386 gcc 4.2.4 glibc 2.7, it cannot > be reproduced. > > I think we need do more work on it and need more people's help. > > Thanks, > Hui > > On Thu, Nov 5, 2009 at 02:29, Michael Snyder <msnyder@vmware.com> wrote: >> Hui Zhu wrote: >>> >>> Hi Michael, >>> >>> I make a patch to fix it. I try in i386-ubuntu. It is OK now. >>> Please help me review it. >>> >>> Thanks, >>> Hui >>> >>> 2009-11-04 Hui Zhu <teawater@gmail.com> >>> >>> * gcore.c (gcore_copy_callback): Remove bfd_get_section_flags >>> check. >>> >>> --- >>> gcore.c | 4 ---- >>> 1 file changed, 4 deletions(-) >>> >>> --- a/gcore.c >>> +++ b/gcore.c >>> @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection >>> struct cleanup *old_chain = NULL; >>> void *memhunk; >>> >>> - /* Read-only sections are marked; we don't have to copy their contents. >>> */ >>> - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) >>> - return; >>> - >>> /* Only interested in "load" sections. */ >>> if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) >>> return; >>> >> >> No, this is not acceptable. We can't save ALL of the loadable >> sections, it will make the gcore file much bigger than necessary. >> Most loadable sections are code, and do not need to be saved. >> >> We will need to choose explicitly just the loadable sections >> that we need to save. >> >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-11-05 2:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-31 17:41 About the gdb prec save/restore reverse exec behavior error (gcore error) Hui Zhu
[not found] ` <4AEC74B8.9090908@vmware.com>
2009-11-04 6:56 ` Hui Zhu
2009-11-04 18:29 ` Michael Snyder
2009-11-05 2:24 ` Hui Zhu
2009-11-05 2:26 ` Hui Zhu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox