|
From: jee <hou...@gm...> - 2012-02-23 12:51:42
|
My code change itself with running, and, I use VALGRIND_DISCARD_TRANSLATIONS with I changed the function's assembly code. and my code is pure C++. i rewrite the assembly code like this: inline hook: mov addr, %rax jmp *%rax I insert this assembly code to the begin of functions, I can run my elf fine. but with valgrind, the code's behavior is....random. mostly, it goto deadly lock. |
|
From: Eliot M. <mo...@cs...> - 2012-02-23 13:02:40
|
On 2/23/2012 7:51 AM, jee wrote: > My code change itself with running, and, I use VALGRIND_DISCARD_TRANSLATIONS with I changed the > function's assembly code. > > and my code is pure C++. i rewrite the assembly code like this: > inline hook: > mov addr, %rax > jmp *%rax > I insert this assembly code to the begin of functions, > > I can run my elf fine. but with valgrind, the code's behavior is....random. mostly, it goto deadly lock. You have self-modifying code, so probably need to specify some flavor of the --smc-check option to valgrind. See the man page :-) ... Best wishes -- Eliot Moss |
|
From: jee <hou...@gm...> - 2012-02-23 13:09:18
|
i try the -smc-check=all & -smc-check=all-non-file and also deadly lock if disable the assambly code, the code running fine with valgrind 2012/2/23 jee <hou...@gm...> > > > 2012/2/23 Eliot Moss <mo...@cs...> > >> On 2/23/2012 7:51 AM, jee wrote: >> >>> My code change itself with running, and, I use >>> VALGRIND_DISCARD_TRANSLATIONS with I changed the >>> function's assembly code. >>> >>> and my code is pure C++. i rewrite the assembly code like this: >>> inline hook: >>> mov addr, %rax >>> jmp *%rax >>> I insert this assembly code to the begin of functions, >>> >>> I can run my elf fine. but with valgrind, the code's behavior >>> is....random. mostly, it goto deadly lock. >>> >> >> You have self-modifying code, so probably need to specify >> some flavor of the --smc-check option to valgrind. See the >> man page :-) ... >> >> Best wishes -- Eliot Moss >> > > |
|
From: jee <hou...@gm...> - 2012-02-23 13:34:03
|
like this:
in gdb:
137 while(fgets(buff, PATH_MAX, p_file)){
(gdb) //when i press n, ...... there's no n,it's dead -_-!
my shell is valgrind --tool=memcheck --leak-check=yes --vgdb-error=0
--smc-check=all --max-stackframe=8388608 ./my_elf [ args ]
2012/2/23 jee <hou...@gm...>
> i try the -smc-check=all & -smc-check=all-non-file
> and also deadly lock
> if disable the assambly code, the code running fine with valgrind
>
> 2012/2/23 jee <hou...@gm...>
>>
>>
>> 2012/2/23 Eliot Moss <mo...@cs...>
>>
>>> On 2/23/2012 7:51 AM, jee wrote:
>>>
>>>> My code change itself with running, and, I use
>>>> VALGRIND_DISCARD_TRANSLATIONS with I changed the
>>>> function's assembly code.
>>>>
>>>> and my code is pure C++. i rewrite the assembly code like this:
>>>> inline hook:
>>>> mov addr, %rax
>>>> jmp *%rax
>>>> I insert this assembly code to the begin of functions,
>>>>
>>>> I can run my elf fine. but with valgrind, the code's behavior
>>>> is....random. mostly, it goto deadly lock.
>>>>
>>>
>>> You have self-modifying code, so probably need to specify
>>> some flavor of the --smc-check option to valgrind. See the
>>> man page :-) ...
>>>
>>> Best wishes -- Eliot Moss
>>>
>>
>>
>
|
|
From: Philippe W. <phi...@sk...> - 2012-02-23 20:42:47
|
On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
> like this:
> in gdb:
> 137 while(fgets(buff, PATH_MAX, p_file)){
> (gdb) //when i press n, ...... there's no n,it's dead -_-!
What happens if you press Control-c ?
Control-c should indicate to the Valgrind gdbserver to give back the
control to gdb, and let you do backtrace, info threads, etc ...
to see where it is hanging.
Philippe
|
|
From: jee <hou...@gm...> - 2012-02-24 01:46:29
|
the same,can not pause.
2012/2/24 Philippe Waroquiers <phi...@sk...>
> On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
> > like this:
> > in gdb:
> > 137 while(fgets(buff, PATH_MAX, p_file)){
> > (gdb) //when i press n, ...... there's no n,it's dead -_-!
>
> What happens if you press Control-c ?
>
> Control-c should indicate to the Valgrind gdbserver to give back the
> control to gdb, and let you do backtrace, info threads, etc ...
> to see where it is hanging.
>
>
> Philippe
>
>
>
>
|
|
From: Philippe W. <phi...@sk...> - 2012-02-25 14:35:50
|
On Fri, 2012-02-24 at 09:46 +0800, jee wrote:
> the same,can not pause.
>
> 2012/2/24 Philippe Waroquiers <phi...@sk...>
> On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
> > like this:
> > in gdb:
> > 137 while(fgets(buff, PATH_MAX, p_file)){
> > (gdb) //when i press n, ...... there's no n,it's dead -_-!
>
>
> What happens if you press Control-c ?
>
> Control-c should indicate to the Valgrind gdbserver to give
> back the
> control to gdb, and let you do backtrace, info threads,
> etc ...
> to see where it is hanging.
When it is deadlock, strace should indicate what is being done.
An alternative : you might try to understand the difference between a
native run
and a run under valgrind using a gdb on the native run
and a gdb connected to Valgrind gdbserver (using --vgdb=full)
and then using si gdb command from a certain point onwards.
Philippe
|
|
From: jee <hou...@gm...> - 2012-02-27 06:13:27
|
I can't stop the gdb useing ctrl-c.
Is there any need to "si" ? If so, this is a bug of valgrind, they should
make sure of the assembly code is right.
"a run under valgrind using a gdb on the native run" you mean" gdb --args
valgrind [args]" ?
2012/2/25 Philippe Waroquiers <phi...@sk...>
> On Fri, 2012-02-24 at 09:46 +0800, jee wrote:
> > the same,can not pause.
> >
> > 2012/2/24 Philippe Waroquiers <phi...@sk...>
> > On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
> > > like this:
> > > in gdb:
> > > 137 while(fgets(buff, PATH_MAX, p_file)){
> > > (gdb) //when i press n, ...... there's no n,it's dead -_-!
> >
> >
> > What happens if you press Control-c ?
> >
> > Control-c should indicate to the Valgrind gdbserver to give
> > back the
> > control to gdb, and let you do backtrace, info threads,
> > etc ...
> > to see where it is hanging.
>
> When it is deadlock, strace should indicate what is being done.
>
> An alternative : you might try to understand the difference between a
> native run
> and a run under valgrind using a gdb on the native run
> and a gdb connected to Valgrind gdbserver (using --vgdb=full)
>
> and then using si gdb command from a certain point onwards.
>
>
> Philippe
>
>
>
>
|
|
From: Philippe W. <phi...@sk...> - 2012-02-27 06:34:14
|
> I can't stop the gdb useing ctrl-c.
> Is there any need to "si" ? If so, this is a bug of valgrind, they should make sure of the assembly code is right.
At this moment, it is not clear what is wrong. It might be a bug or limitation in Valgrind, it might
be something in your program.
> "a run under valgrind using a gdb on the native run" you mean" gdb --args valgrind [args]" ?
The idea is to compare an execution of your program directly under gdb
with an execution under Valgrind, with a gdb connected to the Valgrind gdbserver.
You start valgrind the following way:
valgrind --vgdb=full --vgdb-error=0 ... your program ...
In another window, you start gdb:
gdb ... your program ...
... here you use target remote | vgdb to connect to valgrind gdbserver
.... you put breakpoints at the relevant places
.... you use the gdb continue command,
... and then you use 'si'
In 3rd window, you start your program under gdb
gdb ... your program ...
... put the same breakpoints as above
run and then in parallel use 'si' here and in the other gdb.
You can then compare what a native run is doing and what Valgrind is doing.
Philippe
|
|
From: Julian S. <js...@ac...> - 2012-02-23 14:07:11
|
On Thursday, February 23, 2012 02:02:23 PM Eliot Moss wrote: > On 2/23/2012 7:51 AM, jee wrote: > > My code change itself with running, and, I use > > VALGRIND_DISCARD_TRANSLATIONS with I changed the function's assembly > You have self-modifying code, so probably need to specify > some flavor of the --smc-check option to valgrind. See the They are mutually redundant (in this case). VALGRIND_DISCARD_TRANSLATIONS is a way for the program to feed invalidation hints to Valgrind, so as to tell it to discard translations without invoking the overheads of --smc-check=all or all-non-file. J |