|
From: John C. <jo...@jc...> - 2006-07-25 15:52:47
|
Hi guys. I have a few 'strange' issues: 1) During debugging of a gnome/gtk+ program, where I write/update images in a 'Drawing Area', these are not correctly updated. Could this be because this is probably done in the idle loop of gtk, and the slowness impedes that? In fact, several 'draw' events seem to disappear. 2) I received this messages: ==30877== Conditional jump or move depends on uninitialised value(s) ==30877== at 0x8050261: chirp_ok_btn_clicked (aux.c:310) which was correct... I corrected the source code, recompiled (correctly) and strangely enough, the message still appears. Are the results of valgrind cached somewhere? Suggestions appreciated. John |
|
From: Dennis L. <pla...@pr...> - 2006-07-25 16:20:29
|
Am Dienstag, den 25.07.2006, 12:52 -0300 schrieb John Coppens: > Hi guys. > > I have a few 'strange' issues: > > 1) During debugging of a gnome/gtk+ program, where I write/update images > in a 'Drawing Area', these are not correctly updated. Could this be > because this is probably done in the idle loop of gtk, and the slowness > impedes that? I have no idea how the loop of gtk works, but if it drops events, in case the system is not fast enough, it could as well be, since V is somewhat slow > > In fact, several 'draw' events seem to disappear. > > 2) I received this messages: > > ==30877== Conditional jump or move depends on uninitialised value(s) > ==30877== at 0x8050261: chirp_ok_btn_clicked (aux.c:310) > > which was correct... I corrected the source code, recompiled (correctly) > and strangely enough, the message still appears. Are the results of > valgrind cached somewhere? Make sure your binaries are not the old ones. V does not cache any results, so it could as well be (and isnt that unlikely) that another undefined bit(s) slipped into that condition. You can hunt them down to the origin by littering your code with some valgrind client requests that check for definedness. greets Dennis |
|
From: John C. <jo...@jc...> - 2006-07-26 05:14:23
|
On Tue, 25 Jul 2006 18:20:07 +0200 Dennis Lubert <pla...@pr...> wrote: > Am Dienstag, den 25.07.2006, 12:52 -0300 schrieb John Coppens: > > Hi guys. > > > > I have a few 'strange' issues: > > > > 1) During debugging of a gnome/gtk+ program, where I write/update > > images in a 'Drawing Area', these are not correctly updated. Could > > this be because this is probably done in the idle loop of gtk, and > > the slowness impedes that? > I have no idea how the loop of gtk works, but if it drops events, in > case the system is not fast enough, it could as well be, since V is > somewhat slow > > > > In fact, several 'draw' events seem to disappear. Hi Dennis. Thanks for the reply. When valgrind is running, I have about a 20% CPU load, which should be ok, I suppose. The strange thing is that actual drawing commands are not executed. But I suspect timing to be a problem. > > ,,,(correctly) and strangely enough, the message still appears. Are > > the results of valgrind cached somewhere? > Make sure your binaries are not the old ones. V does not cache any > results, so it could as well be (and isnt that unlikely) that another > undefined bit(s) slipped into that condition. You can hunt them down to > the origin by littering your code with some valgrind client requests > that check for definedness. That was stupid of me... I didn't realize valgrind uses the shell's path to look for the executable. (I believe gdb doesn't) So it found the executable on the path first. Thanks for the hint John |
|
From: Nicholas N. <nj...@cs...> - 2006-07-26 07:13:21
|
On Wed, 26 Jul 2006, John Coppens wrote: >> Make sure your binaries are not the old ones. V does not cache any >> results, so it could as well be (and isnt that unlikely) that another >> undefined bit(s) slipped into that condition. You can hunt them down to >> the origin by littering your code with some valgrind client requests >> that check for definedness. > > That was stupid of me... I didn't realize valgrind uses the shell's path > to look for the executable. (I believe gdb doesn't) So it found the > executable on the path first. Yes, Valgrind tries to execute the program as much as possible as if it was run natively, and that includes looking up the path. Nick |