Differences between program runs with and without gdb

Differences between program runs with and without gdb

[Christoph Bartoschek]

Hi,

is there a list of things that could be different between to runs of a 
programm once with and once without running it under gdb?

I have a programm that calls the custom memory allocator less often when run 
under gdb. Now I search for all possible causes for this behaviour.

Christoph

Re: Differences between program runs with and without gdb

[Joel Brobecker]

> is there a list of things that could be different between to runs of a 
> programm once with and once without running it under gdb?

Generally speaking, GDB tries to be as unobstructive as possible.
In practice, although the debugger interferes very little with
the program execution, it's not completely perfect. The part that
GDB might interfere with which comes first to my mind is thread
scheduling and, to a very small degree, program performance.

-- 
Joel

Re: Differences between program runs with and without gdb

[Christoph Bartoschek]

Am Mittwoch, 10. Januar 2007 15:36 schrieb Joel Brobecker:
> Generally speaking, GDB tries to be as unobstructive as possible.
> In practice, although the debugger interferes very little with
> the program execution, it's not completely perfect. The part that
> GDB might interfere with which comes first to my mind is thread
> scheduling and, to a very small degree

Hi,

both parts do not emplain my problem. First the program is single threaded and 
uses no signals. Second it does not measure time and behaves deterministic. 
Therefore performance differences should have no effect.

Christoph Bartoschek

Re: Differences between program runs with and without gdb

[Markus Deuling]

Hi Christoph,

Christoph Bartoschek schrieb:
> both parts do not emplain my problem. First the program is single threaded and 
> uses no signals. Second it does not measure time and behaves deterministic. 
> Therefore performance differences should have no effect.

how do you measure that gdb makes your app call memory allocation less often ?



Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com 

Re: Differences between program runs with and without gdb

[Andrew STUBBS]

Christoph Bartoschek wrote:
> both parts do not emplain my problem. First the program is single threaded and 
> uses no signals. Second it does not measure time and behaves deterministic. 
> Therefore performance differences should have no effect.

Does it make a difference when you run under GDB, but without using 
stepping/breakpoints or other explicit commands?

In other words, what might you be asking GDB to do to your program?

Andrew

Re: Differences between program runs with and without gdb

[Christoph Bartoschek]

Am Mittwoch, 10. Januar 2007 15:53 schrieb Markus Deuling:
> Hi Christoph,
>
> Christoph Bartoschek schrieb:
> > both parts do not emplain my problem. First the program is single
> > threaded and uses no signals. Second it does not measure time and behaves
> > deterministic. Therefore performance differences should have no effect.
>
> how do you measure that gdb makes your app call memory allocation less
> often ?

Just print a string each time the allocation is called. And then diff the 
normal run and the gdb run.

Christoph

Re: Differences between program runs with and without gdb

[Christoph Bartoschek]

Am Mittwoch, 10. Januar 2007 15:57 schrieb Andrew STUBBS:
> Christoph Bartoschek wrote:
> > both parts do not emplain my problem. First the program is single
> > threaded and uses no signals. Second it does not measure time and behaves
> > deterministic. Therefore performance differences should have no effect.
>
> Does it make a difference when you run under GDB, but without using
> stepping/breakpoints or other explicit commands?
>
> In other words, what might you be asking GDB to do to your program?

There is no stepping and no breakpoints are active. The program starts, it 
terminates and the debugger is quitted. 

The program has no user interaction.

Christoph

Re: Differences between program runs with and without gdb

[Andrew STUBBS]

Christoph Bartoschek wrote:
> There is no stepping and no breakpoints are active. The program starts, it 
> terminates and the debugger is quitted. 

In that case GDB is still quietly and automatically monitoring threads 
and signals, of which you say there are none, and also the dynamic 
linker. I don't know what system you are on or what your program does 
but it may be that there is an invisible breakpoint every time a library 
is loaded (GDB uses them to load the symbols from the library). I don't 
know how that could be affecting anything though. It's possible that a 
breakpoint has been set on some data somehow - if you have a symbol with 
just the wrong name.

Perhaps you pass in slightly different parameters or environment when 
you use GDB. I expect you checked this already.

There's always cache effects of course. Perhaps your program does 
something unsafe (self modifying code?) and GDB's influence is just 
enough to perturb the results.

Instead of GDB, have you tried running it "under" something else. ptrace 
or valgrind perhaps, assuming your on a compatible system.

Well there's some ideas anyway.

Andrew

Re: Differences between program runs with and without gdb

[Christoph Bartoschek]

Am Mittwoch, 10. Januar 2007 15:17 schrieb Christoph Bartoschek:
> Hi,
>
> is there a list of things that could be different between to runs of a
> programm once with and once without running it under gdb?
>
> I have a programm that calls the custom memory allocator less often when
> run under gdb. Now I search for all possible causes for this behaviour.
>


Hi,

thanks to all that helped.

I've just found the problem. When the program is started with gdb the 
commandline differs. This means that argv[0] is different and that has the 
effect that our commandline parser needs a different number of allocations.

Starting the programm with:

gdb ./prog

results in an argv[0] of

/home/ponto/source/prog 

Starting it with

./prog

results in an argv[0] of

./prog


Greetings 
Christoph Bartoschek