|
From: George H. <kh...@op...> - 2004-06-05 15:53:37
|
Hi,
I am attempting to use the CVS version of valgrind on a Fedora Core 2
box. I have patch the vg_libpthread.c file as suggested by others on this
mailing list, however I still get a segmentation fault when I run any
valgrind
tool. Others have also reported this behavior, and they also indicated
that GDB gives useless information when a stack trace is requested. I built
a debug version of valgrind, ran the valgrind under GDB with a break
point set in main and then single-stepped through until I found where the
seg-fault is occurring.
It appears that the problem is in the ume_go function called from line 195
in stage1.c. The variables passed into are:
info.init_eip : 2952792000
(addr_t)esp : 0xfeecc7e0
GDB also reports that esp is a pointer to an integer, examining the memory
at that location gives:
(gdb) x/16b 0xfeecc7dc
0xfeecc7dc: 0x0c 0x97 0x04 0x08 0x03 0x00 0x00 0x00
0xfeecc7e4: 0xcc 0xdb 0x0f0 0xfe 0xe5 0xdb 0xf0 0xfe
which means that *esp is really 0x00000003.
I do not understand the internals of valgrind enough to figure out what is
going wrong, I just hope that this information helps someone else. The
`script' file of my debugging attempt is attached below.
===============start script===========================
(gdb) set args --tool=memcheck ls
(gdb) break main
Breakpoint 1 at 0x804856b: file stage1.c, line 201.
(gdb) run
Starting program: /root/debug/bin/valgrind --tool=memcheck ls
Breakpoint 1, main (argc=0, argv=0xfef47b84) at stage1.c:201
201 const char *cp = getenv(VALGRINDLIB);
(gdb) n
203 if (cp != NULL)
(gdb) n
206 assert(ume_exec_esp != NULL);
(gdb) n
208 our_argc = argc;
(gdb) n
212 getrlimit(RLIMIT_AS, &rlim);
(gdb)
213 rlim.rlim_cur = rlim.rlim_max;
(gdb)
214 setrlimit(RLIMIT_AS, &rlim);
(gdb)
217 ume_go((addr_t)hoops, (addr_t)stack + sizeof(stack));
(gdb)
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x005ce402 in ?? ()
(gdb) where
#0 0x005ce402 in ?? ()
#1 0xb00d27b6 in ?? ()
#2 0xb8022c7d in ?? ()
#3 0x00000000 in ?? ()
running a second time, this time stepping into ume_go produces the
following:
217 ume_go((addr_t)hoops, (addr_t)stack + sizeof(stack));
(gdb) s
ume_go (eip=134513803, esp=135024832) at x86/ume_go.c:36
36 asm volatile ("movl %1, %%esp;" /* set esp */
(gdb) n
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x3: Input/output error.
(gdb) n
154 char buf[strlen(valgrind_lib) + sizeof(stage2) + 16];
(gdb) n
156 info.exe_base = PGROUNDUP(&_end);
(gdb) n
157 info.exe_end = PGROUNDDN(ume_exec_esp);
(gdb) n
165 info.map_base = 0xb0000000;
(gdb) n
166 info.argv = NULL;
(gdb) n
168 snprintf(buf, sizeof(buf), "%s/%s", valgrind_lib, stage2);
(gdb) n
170 err = do_exec(buf, &info);
(gdb) n
172 if (err != 0) {
(gdb) n
180 as_pad(0, (void *)info.map_base);
(gdb)
182 esp = fix_auxv(ume_exec_esp, &info);
(gdb)
184 if (0) {
(gdb)
195 ume_go(info.init_eip, (addr_t)esp);
(gdb) s
ume_go (eip=2952792000, esp=4276635680) at x86/ume_go.c:36
36 asm volatile ("movl %1, %%esp;" /* set esp */
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x007a6402 in ?? ()
===================== end script ==================================
Hope this helps someone,
George Huber
|
|
From: Tom H. <th...@cy...> - 2004-06-05 16:34:38
|
In message <008701c44b15$42a061e0$0201a8c0@aelfin.local>
George Huber <kh...@op...> wrote:
> I am attempting to use the CVS version of valgrind on a Fedora Core 2
> box. I have patch the vg_libpthread.c file as suggested by others on this
> mailing list, however I still get a segmentation fault when I run any
> valgrind tool.
If your CVS checkout is up to date and you turn vdso support off then
valgrind should run fine on FC2 without any extra patches. It certainly
does for me.
> Others have also reported this behavior, and they also indicated
> that GDB gives useless information when a stack trace is requested. I built
> a debug version of valgrind, ran the valgrind under GDB with a break
> point set in main and then single-stepped through until I found where the
> seg-fault is occurring.
It isn't generally possibly to debug valgrind by running it directly
under gdb unless it happens to be failing very early. In other cases
you will have to use --wait-for-gdb=yes and then attach gdb to it in
order to see the correct state of valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|