|
From: Rob H. <ti...@ge...> - 2005-08-18 19:17:16
|
Hola, Ok, so the next stumbling block... All the client request stuff is working wonderfully. I'm really happy with all the neat stuff I can do with the valgrind framework, it's really excellent. I have only one small problem now which is that I can't get at the originals for functions I've replaced. The reason I need this is that I need to audit the format strings only once per series of *printf calls. To explain that a little, most *printf calls actually call another *printf call themselves to do the end work. I need to make sure I only check the format string on the call the client actually made, and not the internal ones that follow. In the preload library which Tavis wrote, we took pointers to the original functions on load. The trouble is that valgrind does redirection based on address and not name. So, when the *printf functions call another *printf function, that is redirected as well. It makes a bit of a mess :) So, I'm trying to think of a way to get at the original versions so I can call those from my wrappers. Any ideas? I could take note of the calling stack frame and then ignore the format string for anything below the initial frame. But, seems a bit ugly :/ I could use a VG_(really_call_the_function_please)(printf). Is there something like this already? Or would it be a good idea for me to try and write one? I'm not sure if this is something anyone else would find useful (hence not sure if it's suitable for inclusion in "mainline"), and I wouldn't want to have to always patch valgrind to use my tool, so I'm looking for suggestions for sane solutions. Many thanks, Rob --=20 |
|
From: Rob H. <ti...@ge...> - 2005-08-18 20:55:34
|
Tavis pointed out a hack which fixes the problem. I can get a local copy
of glibc with dlopen("/lib/libc.so.6", RTLD_LOCAL | RTLD_NOW) and use
those symbols for the pointers instead.
Cheers,
Rob
--=20
|
|
From: Tom H. <to...@co...> - 2005-08-18 22:14:15
|
In message <1124398531.3856.27.camel@localhost.localdomain>
Rob Holland <ti...@ge...> wrote:
> Tavis pointed out a hack which fixes the problem. I can get a local copy
> of glibc with dlopen("/lib/libc.so.6", RTLD_LOCAL | RTLD_NOW) and use
> those symbols for the pointers instead.
I'd be surprised if that works - that dlopen would normally return a
handle for the existing C library which would meand the symbols have
the same address and would get redirected again.
If it did load a second copy of the C library you would still have a
problem as the two C libraries would have different copies of any
static data the C library uses internally.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-18 22:14:56
|
In message <1124392626.3856.21.camel@localhost.localdomain>
Rob Holland <ti...@ge...> wrote:
> I have only one small problem now which is that I can't get at the
> originals for functions I've replaced. The reason I need this is that I
> need to audit the format strings only once per series of *printf calls.
> To explain that a little, most *printf calls actually call another
> *printf call themselves to do the end work.
I did wonder about that yesterday, but I assumed you must be planning
to implement the functions yourself.
What you need is the function wrapping code that Jeremy developed for
thread modelling but that is currently not functional in the 3.0 tree.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rob H. <ti...@ge...> - 2005-08-18 22:27:17
|
On Thu, 2005-08-18 at 23:13 +0100, Tom Hughes wrote: > I'd be surprised if that works - that dlopen would normally return a > handle for the existing C library which would meand the symbols have > the same address and would get redirected again. It does work :) tigger@xahn % valgrind --tool=3Dformatcheck /tmp/test =3D=3D24444=3D=3D formatcheck, format string check. =3D=3D24444=3D=3D Copyright (C) 2005, and GNU GPL'd, by Rob Holland. =3D=3D24444=3D=3D Using LibVEX rev 1338, a library for dynamic binary translation. =3D=3D24444=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D24444=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D24444=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D24444=3D=3D For more details, rerun with: -v =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string with no specifiers: 'rabbits' =3D=3D24444=3D=3D at 0x2571B94B: sprintf (fc_replace_format_functions.c:= 141) =3D=3D24444=3D=3D by 0x400647: main (test.c:5) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string is not a literal (appears to be from heap):= 'foo %s' =3D=3D24444=3D=3D at 0x2571B5FA: printf (fc_replace_format_functions.c:9= 6) =3D=3D24444=3D=3D by 0x400663: main (test.c:6) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string is not a literal (appears to be from heap): 'rabbits' =3D=3D24444=3D=3D at 0x2571B5FA: printf (fc_replace_format_functions.c:9= 6) =3D=3D24444=3D=3D by 0x400671: main (test.c:7) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string was target of previous s*printf: 'rabbits' =3D=3D24444=3D=3D at 0x2571B5FA: printf (fc_replace_format_functions.c:9= 6) =3D=3D24444=3D=3D by 0x400671: main (test.c:7) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string with no specifiers: 'rabbits' =3D=3D24444=3D=3D at 0x2571B648: printf (fc_replace_format_functions.c:1= 00) =3D=3D24444=3D=3D by 0x400671: main (test.c:7) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string is not a literal (appears to be from heap): 'eh?' =3D=3D24444=3D=3D at 0x2571B755: fprintf (fc_replace_format_functions.c:= 116) =3D=3D24444=3D=3D by 0x40068F: main (test.c:8) =3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D Format string with no specifiers: 'eh?' =3D=3D24444=3D=3D at 0x2571B7A6: fprintf (fc_replace_format_functions.c:= 120) =3D=3D24444=3D=3D by 0x40068F: main (test.c:8) eh?foo bearrabbits=3D=3D24444=3D=3D=20 =3D=3D24444=3D=3D ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 fr= om 0) --=20 |
|
From: Nicholas N. <nj...@cs...> - 2005-08-23 15:16:31
|
On Thu, 18 Aug 2005, Rob Holland wrote: > On Thu, 2005-08-18 at 23:13 +0100, Tom Hughes wrote: >> I'd be surprised if that works - that dlopen would normally return a >> handle for the existing C library which would meand the symbols have >> the same address and would get redirected again. > > It does work :) Something to note: Julian's planning on removing Valgrind's (currently small) dependence on glibc entirely, in which case you won't be able to use dlopen(). So as Tom said, what you need here are function wrappers rather than function replacements; Jeremy started adding support for them (see the bottom section of coregrind/m_redir.c, under "General function wrapping") but it's currently all commented out and I'm not sure if it was working properly. It's interesting, your tool is a bit different to the existing ones and so is stressing the core/tool interface in new ways. I'm keen to help you with this; if it's helpful I can take a look at the wrapping code, although my hacking time is limited. N |
|
From: Rob H. <ti...@ge...> - 2005-08-18 23:03:18
|
On Thu, 2005-08-18 at 23:26 +0100, Rob Holland wrote: > It does work :) Or not.... The source is at: http://dev.gentoo.org/~tigger/formatcheck.tar.bz2 in case anyone has any ideas. I can't see what's up unless it's the second libc load that's annoying cli_malloc in some way. It's the VG_(cli_malloc) in fc_main.c:new_block() that's causing the segfault. =3D=3D27492=3D=3D formatcheck, format string check. =3D=3D27492=3D=3D Copyright (C) 2005, and GNU GPL'd, by Rob Holland. =3D=3D27492=3D=3D Using LibVEX rev 1338, a library for dynamic binary translation. =3D=3D27492=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D27492=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D27492=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D27492=3D=3D For more details, rerun with: -v =3D=3D27492=3D=3D=20 =3D=3D27492=3D=3D Format string is not a literal (appears to be from heap):= '%d' =3D=3D27492=3D=3D at 0x2571B8BE: sprintf (fc_replace_format_functions.c:= 135) =3D=3D27492=3D=3D by 0x25978FE7: tparm (in /lib64/libncurses.so.5.4) =3D=3D27492=3D=3D by 0x402FA9: capsmk (top.c:523) =3D=3D27492=3D=3D by 0x408065: main (top.c:2395) =3D=3D27492=3D=3D=20 =3D=3D27492=3D=3D Format string is not a literal (appears to be from heap):= '%d' =3D=3D27492=3D=3D at 0x2571B8BE: sprintf (fc_replace_format_functions.c:= 135) =3D=3D27492=3D=3D by 0x25978FE7: tparm (in /lib64/libncurses.so.5.4) =3D=3D27492=3D=3D by 0x402FA9: capsmk (top.c:523) =3D=3D27492=3D=3D by 0x408065: main (top.c:2395) --27492-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --27492-- si_code=3D1; Faulting address: 0x4BB82F10; sp: 0x7015CDD0 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D27492=3D=3D at 0x70023B18: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D27492=3D=3D at 0x25719B86: malloc (vg_replace_malloc.c:149) =3D=3D27492=3D=3D by 0x25507EF4: _dl_new_object (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x255047B9: _dl_map_object_from_fd (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25505FAE: _dl_map_object (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25508FFC: openaux (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x255092F1: _dl_map_object_deps (in /lib64/ld-2.3.5= .so) =3D=3D27492=3D=3D by 0x25B7C382: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7CB99: _dl_open (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DF37: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DEFA: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DFC7: __libc_dlopen_mode (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B5BA5A: __nss_lookup_function (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B5BB53: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B225A0: getpwuid_r (in /lib64/tls/libc-2.3.5.so= ) =3D=3D27492=3D=3D by 0x25B21E6C: getpwuid (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2582FAD6: user_from_uid (pwcache.c:42) =3D=3D27492=3D=3D by 0x25830960: simple_readproc (readproc.c:531) =3D=3D27492=3D=3D by 0x25831025: readproc (readproc.c:743) =3D=3D27492=3D=3D by 0x403DD8: procs_refresh (top.c:1107) =3D=3D27492=3D=3D by 0x406CE9: frame_make (top.c:2848) =3D=3D27492=3D=3D by 0x40811F: main (top.c:3259) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. --=20 |
|
From: Rob H. <ti...@ge...> - 2005-08-19 22:35:26
|
Just in case the error wasn't unique to my code, I tried massif. It does the same thing :/ tigger@xahn % valgrind --tool=3Dmassif =3D=3D26577=3D=3D Massif, a space profiler. =3D=3D26577=3D=3D Copyright (C) 2003, Nicholas Nethercote =3D=3D26577=3D=3D Using LibVEX rev 1338, a library for dynamic binary translation. =3D=3D26577=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D26577=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D26577=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D26577=3D=3D For more details, rerun with: -v =3D=3D26577=3D=3D=20 --26577-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --26577-- si_code=3D1; Faulting address: 0x4B96DE80; sp: 0x7015CDC0 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D26577=3D=3D at 0x70023C78: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D26577=3D=3D at 0x25719796: malloc (vg_replace_malloc.c:149) =3D=3D26577=3D=3D by 0x492AAE: lalloc (misc2.c:843) =3D=3D26577=3D=3D by 0x4929D9: alloc (misc2.c:742) =3D=3D26577=3D=3D by 0x492B69: vim_strsave (misc2.c:940) =3D=3D26577=3D=3D by 0x4B7ACB: set_string_option_global (option.c:4547) =3D=3D26577=3D=3D by 0x4B79FF: set_string_option_direct (option.c:4518) =3D=3D26577=3D=3D by 0x4B4D95: set_option_default (option.c:2870) =3D=3D26577=3D=3D by 0x4B4F42: set_options_default (option.c:2924) =3D=3D26577=3D=3D by 0x4B4A52: set_init_1 (option.c:2678) =3D=3D26577=3D=3D by 0x46D90E: main (main.c:361) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. --=20 |
|
From: Rob H. <ti...@ge...> - 2005-08-22 12:54:06
|
On Fri, 2005-08-19 at 23:35 +0100, Rob Holland wrote: > Just in case the error wasn't unique to my code, I tried massif. It does > the same thing :/ Another developer has tried massif on his 64bit box and has the same errors. So, guessing it's a 32/64 bit buglet. Any clues? :) --=20 |