|
From: Yu H. <yu...@nc...> - 2010-12-21 03:43:20
|
Hi all,
Is there any easy way to get app's start and end address of code, data,
heap, stack and BSS segments?
Hooking functions such as malloc, mmap can capture memory allocation (
what Massif do ). But I think this way is too heavy to me, and I'm not
sure such a way can solve my problem either. Since Valgrind has a
embeded linker, I believe it has something to manage the memory layout.
Here is what I want to do:
> Lackey gives an address, such as 0x7FF0008E8,
> *I want to determine which segment does the address points to.
*
> If I have a directory like below, I then can easily achive my goal.
"heap":[0x1000000, 0x2000000]
"text":[0x3C00000, 0x3F00000]
etc...
> Is it possible for me to build such a directory?
Thank you and Merry Xmas!
----
Ray
Chiese Academy of Sciences, Beijing, China.
|
|
From: Osman, A. <ahm...@me...> - 2010-12-23 18:18:29
|
Hi All,
I'm trying to understand what valgrind 3.5 is complaining about in the
only db_if.c item in the latest valgrind report.
==46991== Conditional jump or move depends on uninitialised value(s)
==46991== at 0x88B1386: sortReadersWriters (db_if.c:7036)
==46991== by 0x88B1CA2: add_procs_from_debug_section_to_db
(db_if.c:7219)
...
The code at db_if.c:7036 is in red below:
for (i=0; i < count2; i += 2) {
/* the instance name will have a subscript, compare name up to the
subscript */
if (!strncmp(list2[i+1], name, nameLen) && list2[i+1][nameLen] ==
'[') {
int idx;
int length;
/* compute index of instance, ignore the instance array itself
*/
int ss = sscanf(list2[i+1]+nameLen,"[%d]%n", &idx, &length);
if ((ss == 1) && (length == strlen(list2[i+1])-nameLen) ) {
It appears that everything used in that line is set. Might valgrind not
recognize the values set to idx and length in the call to sscanf()?
- Osman
|
|
From: David W. <dw...@in...> - 2010-12-23 19:14:57
|
On Thu, 2010-12-23 at 10:18 -0800, Osman, Ahmed wrote: > > > I'm trying to understand what valgrind 3.5 is complaining about in the > only db_if.c item in the latest valgrind report. Hi Ahmed, I'm trying to understand how your question is related to Yu Huang's message about determining which segment an address points is in. You replied to his message, but I don't see the relevance of your question to that thread. Should it have been a new thread of its own? -- dwmw2 |
|
From: Osman, A. <ahm...@me...> - 2010-12-23 18:38:25
|
Sorry I made a mistake. It should be a new thread -----Original Message----- From: David Woodhouse [mailto:dw...@in...] Sent: Thursday, December 23, 2010 10:30 AM To: Osman, Ahmed Cc: val...@li... Subject: Re: [Valgrind-users] False report On Thu, 2010-12-23 at 10:18 -0800, Osman, Ahmed wrote: > > > I'm trying to understand what valgrind 3.5 is complaining about in the > only db_if.c item in the latest valgrind report. Hi Ahmed, I'm trying to understand how your question is related to Yu Huang's message about determining which segment an address points is in. You replied to his message, but I don't see the relevance of your question to that thread. Should it have been a new thread of its own? -- dwmw2 |
|
From: Dallman, J. <joh...@si...> - 2010-12-23 18:38:56
|
> It appears that everything used in that line is set. Might
> valgrind not recognize the values set to idx and length in
> the call to sscanf()?
With puzzling things like this, try simply printing the values in
question with printf(). This usually clarifies the situation.
--
John Dallman
From: Osman, Ahmed [mailto:ahm...@me...]
Sent: 23 December 2010 18:18
To: val...@li...
Subject: [Valgrind-users] False report
Hi All,
I'm trying to understand what valgrind 3.5 is complaining about in the only db_if.c item in the latest valgrind report.
==46991== Conditional jump or move depends on uninitialised value(s)
==46991== at 0x88B1386: sortReadersWriters (db_if.c:7036)
==46991== by 0x88B1CA2: add_procs_from_debug_section_to_db (db_if.c:7219)
...
The code at db_if.c:7036 is in red below:
for (i=0; i < count2; i += 2) {
/* the instance name will have a subscript, compare name up to the subscript */
if (!strncmp(list2[i+1], name, nameLen) && list2[i+1][nameLen] == '[') {
int idx;
int length;
/* compute index of instance, ignore the instance array itself */
int ss = sscanf(list2[i+1]+nameLen,"[%d]%n", &idx, &length);
if ((ss == 1) && (length == strlen(list2[i+1])-nameLen) ) {
It appears that everything used in that line is set. Might valgrind not recognize the values set to idx and length in the call to sscanf()?
- Osman
|
|
From: Dave G. <go...@mc...> - 2010-12-23 18:52:01
|
On Dec 23, 2010, at 12:25 PM CST, Dallman, John wrote: >> It appears that everything used in that line is set. Might >> valgrind not recognize the values set to idx and length in >> the call to sscanf()? > > With puzzling things like this, try simply printing the values in > question with printf(). This usually clarifies the situation. Passing "--track-origins=yes" to Valgrind also helps when hunting down "uninitialised value" warnings. As a bonus, you don't need to recompile the program to use this strategy. -Dave |
|
From: Osman, A. <ahm...@me...> - 2010-12-23 21:57:34
|
Hi Dave,
I added it and thisis the report.
==9502== Memcheck, a memory error detector
==9502== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9502== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright
info
==9502== Command: /u/bata_root/rhino/valgrind/modeltech/linux/vsimk
-valgrind -port 49597 -stdoutfilename /tmp/VSOUT6oSNMl -novopt -c
-debugdb=test1.dbg -wlf test1.wlf -do test1.do top_opt
==9502== Parent PID: 9493
==9502==
==9502== Conditional jump or move depends on uninitialised value(s)
==9502== at 0x88B3BDD: sortReadersWriters (db_if.c:7071)
==9502== by 0x88B44F9: add_procs_from_debug_section_to_db
(db_if.c:7254)
==9502== by 0x88B4C56: add_procs_from_debug_section_to_db2
(db_if.c:7462)
==9502== by 0x88B49DA: add_procs_from_debug_section_to_db
(db_if.c:7371)
==9502== by 0x88B4C56: add_procs_from_debug_section_to_db2
(db_if.c:7462)
==9502== by 0x88BACA6: insertSchematicInstance (db_if.c:9822)
==9502== by 0x88BADA6: insertSchematicInstance (db_if.c:9853)
==9502== by 0x88BB9AA: setOrdinal_DebugDB (db_if.c:10183)
==9502== by 0x88BBBDD: Finalize2 (db_if.c:10270)
==9502== by 0x88BBCA9: Finalize2 (db_if.c:10296)
==9502== by 0x88BC967: SaveDesignInfo (db_if.c:10620)
==9502== by 0x88C017D: writeDebugDB (db_if.c:11393)
==9502== by 0x88C0299: close_DebugDB (db_if.c:11437)
==9502== by 0x8407C27: vsimsetup (vsetup.c:3810)
==9502== by 0x873D278: tclprim_LoadDesign (tclcmd.c:1175)
==9502== by 0x8B64FAB: TclInvokeStringCommand (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B6675D: TclEvalObjvInternal (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B8C08F: TclExecuteByteCode (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B91177: TclCompEvalObj (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B686F0: Tcl_EvalObjEx (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B6B7A1: Tcl_CatchObjCmd (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B6675D: TclEvalObjvInternal (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B8C08F: TclExecuteByteCode (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B913D7: Tcl_ExprObj (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B66E70: Tcl_ExprBooleanObj (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B6E571: Tcl_IfObjCmd (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B6675D: TclEvalObjvInternal (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B67BF1: Tcl_EvalEx (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B68034: Tcl_Eval (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8B68A1E: Tcl_GlobalEval (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x889D30B: mti_DoIt (tclrpc.c:850)
==9502== by 0x8B9ED8F: Tcl_NotifyChannel (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8BCD8C2: FileHandlerEventProc (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8BAE1F4: Tcl_ServiceEvent (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8BAE4F2: Tcl_DoOneEvent (in
/u/bata_root/rhino/valgrind/modeltech/linux/vsimk)
==9502== by 0x8AD21AA: mti_DoOneEvent (tclext.c:379)
==9502== by 0x853E98F: bg_execute_commands (bgcmd.c:823)
==9502== by 0x8452F33: mti_main (main.c:2701)
==9502== by 0x805E73E: main (mti_main.c:76)
==9502== Uninitialised value was created by a stack allocation
==9502== at 0x88B393D: sortReadersWriters (db_if.c:7021)
==9502==
What could be the problem? as the line 7021 is this:
static void sortReadersWriters(const char * name, int lbound, int isUp,
int len,
dataflow_symtab_rec *rec,
dataflow_name_rec** rw_arr,
handle obj)
{
-----Original Message-----
From: Dave Goodell [mailto:go...@mc...]
Sent: Thursday, December 23, 2010 10:52 AM
To: Dallman, John
Cc: Osman, Ahmed; val...@li...
Subject: Re: [Valgrind-users] False report
On Dec 23, 2010, at 12:25 PM CST, Dallman, John wrote:
>> It appears that everything used in that line is set. Might
>> valgrind not recognize the values set to idx and length in
>> the call to sscanf()?
>
> With puzzling things like this, try simply printing the values in
> question with printf(). This usually clarifies the situation.
Passing "--track-origins=yes" to Valgrind also helps when hunting down
"uninitialised value" warnings. As a bonus, you don't need to recompile
the program to use this strategy.
-Dave
|
|
From: Dave G. <go...@mc...> - 2010-12-23 22:05:27
|
On Dec 23, 2010, at 3:57 PM CST, Osman, Ahmed wrote:
> Hi Dave,
> I added it and thisis the report.
[...]
> ==9502== Uninitialised value was created by a stack allocation
> ==9502== at 0x88B393D: sortReadersWriters (db_if.c:7021)
> ==9502==
>
> What could be the problem? as the line 7021 is this:
> static void sortReadersWriters(const char * name, int lbound, int isUp,
> int len,
> dataflow_symtab_rec *rec,
> dataflow_name_rec** rw_arr,
> handle obj)
> {
Valgrind is telling you that the uninitialized value is coming from a variable allocated on the stack upon entering that function. For example, the following code would elicit an error like this:
----8<----
void func(void)
{
int i;
if (i > 5) { /*...*/ }
}
----8<----
Because "i" was never initialized, it has an undefined (garbage) value.
So in your case, take a look at any local variables that are declared in that function and see if they are used on line 7071. Then make sure that they will always have been initialized by the time you reach that line.
-Dave
> -----Original Message-----
> From: Dave Goodell [mailto:go...@mc...]
> Sent: Thursday, December 23, 2010 10:52 AM
> To: Dallman, John
> Cc: Osman, Ahmed; val...@li...
> Subject: Re: [Valgrind-users] False report
>
> On Dec 23, 2010, at 12:25 PM CST, Dallman, John wrote:
>
>>> It appears that everything used in that line is set. Might
>>> valgrind not recognize the values set to idx and length in
>>> the call to sscanf()?
>>
>> With puzzling things like this, try simply printing the values in
>> question with printf(). This usually clarifies the situation.
>
> Passing "--track-origins=yes" to Valgrind also helps when hunting down
> "uninitialised value" warnings. As a bonus, you don't need to recompile
> the program to use this strategy.
>
> -Dave
>
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-01-11 15:32:26
|
You might try the gdbserver patch (which allows such an interactive query of what an address is) and/or use the code behind as an example. See http://bugs.kde.org/show_bug.cgi?id=214909 gdb server patch allows to debug a program running under valgrind, and do (some) interactive calls to some of the valgrind tool functionality. Here is a trace of an interactive usage of gdb server in valgrind with memcheck tool, showing a description of an address on the stack an address of text an address on the heap. Hope this helps ... (gdb) mo mc.c add 0xfe82aab0 Address 0xFE82AAB0 len 1 addressable ==30724== Address 0xfe82aab0 is on thread 1's stack (gdb) bt #0 param_test () at /cm/build6/cm/ot/TOOL/ADA_PRIM!15.0.54/build_G!79.IP.L5/sources/param_te st.adb:66 #1 0x0804cf1a in tool_ada_prim_shared_test () at /cm/ot/TOOL/ADA_PRIM!15.0.54/build_G!79.IP.L5/ada/../sources/tool_ada_pr im_shared_test.adb:138 (gdb) mo mc.c add 0x0804cf1a Address 0x804CF1A len 1 addressable ==30724== Address 0x804cf1a is in the Text segment of /cm/build6/cm/ot/TOOL/ADA_PRIM!15.0.54/build_G!79.IP.L5/ada/exe/tool_ada _prim_shared_test (gdb) mo mc.c add 0x727d060 Address 0x727D060 len 1 addressable ==30724== Address 0x727d060 is 0 bytes inside a block of size 10 alloc'd ==30724== at 0x4D80E46: memalign (vg_replace_malloc.c:581) ==30724== by 0x44146D4: malloc (in /lib/ld-2.5.so) ==30724== by 0x804B5BF: ??? (in /cm/build6/cm/ot/TOOL/ADA_PRIM!15.0.54/build_G!79.IP.L5/ada/exe/tool_ada _prim_shared_test) ==30724== by 0x9: ??? (gdb) ________________________________ From: Yu Huang [mailto:yu...@nc...] Sent: Tuesday 21 December 2010 04:43 To: val...@li... Subject: [Valgrind-users] How to determine which segment does an addresspoints to in Valgrind? Hi all, Is there any easy way to get app's start and end address of code, data, heap, stack and BSS segments? Hooking functions such as malloc, mmap can capture memory allocation ( what Massif do ). But I think this way is too heavy to me, and I'm not sure such a way can solve my problem either. Since Valgrind has a embeded linker, I believe it has something to manage the memory layout. Here is what I want to do: > Lackey gives an address, such as 0x7FF0008E8, > I want to determine which segment does the address points to. > If I have a directory like below, I then can easily achive my goal. "heap":[0x1000000, 0x2000000] "text":[0x3C00000, 0x3F00000] etc... > Is it possible for me to build such a directory? Thank you and Merry Xmas! ---- Ray Chiese Academy of Sciences, Beijing, China. ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |