|
From: Asiga N. <asi...@ya...> - 2006-07-19 11:42:19
|
Hi, I'm trying to use Valgrind to debug an OpenGL application. Unfortunately, it causes a total system lock when I quit the application and Valgrind searchs for memory leaks. If I use "--leak-check=no", this problem doesn't seem to happen, although I still haven't done intense testing in order to really confirm this. Searching the mailing list, I see that some people claimed getting system locks when using ATI drivers, but I also found that a bug related to these drivers was fixed in a previous Valgrind version, so I'm not sure what kind of issue I'm facing. I'm using the ATI drivers. I've got the same result (ie:lock) both with Ubuntu Breezy and Ubuntu Dapper, and both with Valgrind 3.1.0 and 3.2.0. Is there anything I could try to get Valgrind working? Will it work fine with "--leak-check=no" ? (well, I need to detect memory leaks, but it's better to have the rest of the memcheck functionality than having nothing at all) Thanks in advance, asiga __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Nicholas N. <nj...@cs...> - 2006-07-19 11:55:25
|
On Wed, 19 Jul 2006, Asiga Nael wrote: > Searching the mailing list, I see that some people > claimed getting system locks when using ATI drivers, > but I also found that a bug related to these drivers > was fixed in a previous Valgrind version, so I'm not > sure what kind of issue I'm facing. IIRC, that bug was fixed in earlier versions but then became "unfixed" a bit later, unfortunately. Nick |
|
From: Asiga N. <asi...@ya...> - 2006-07-20 16:35:56
|
--- Nicholas Nethercote <nj...@cs...> wrote: > On Wed, 19 Jul 2006, Asiga Nael wrote: > > > Searching the mailing list, I see that some people > > claimed getting system locks when using ATI > drivers, > > but I also found that a bug related to these > drivers > > was fixed in a previous Valgrind version, so I'm > not > > sure what kind of issue I'm facing. > > IIRC, that bug was fixed in earlier versions but > then became "unfixed" a bit > later, unfortunately. >From what I see at the mailing list, it seems like very few people use Valgrind together with ATI drivers, so I'm wondering if this bug is considered worthy of being fixed, or if it's given low priority. The fact that both 3.1.0 and 3.2.0 have the bug make me suspect there's no input about this from the user base... In the meantime, I suppose I can use Valgrind except for leaks, and another tool for leaks (because it seems memory leak detection is the only memcheck option that freezes the system). asiga __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Tom H. <to...@co...> - 2006-07-20 16:57:59
|
In message <200...@we...>
Asiga Nael <asi...@ya...> wrote:
> From what I see at the mailing list, it seems like
> very few people use Valgrind together with ATI
> drivers, so I'm wondering if this bug is considered
> worthy of being fixed, or if it's given low priority.
> The fact that both 3.1.0 and 3.2.0 have the bug make
> me suspect there's no input about this from the user
> base...
>
> In the meantime, I suppose I can use Valgrind except
> for leaks, and another tool for leaks (because it
> seems memory leak detection is the only memcheck
> option that freezes the system).
It's far more likely that somebody will get around to looking at
this if a bug is filed in the bug tracker...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-07-20 17:00:36
|
I don't think it would be hard to fix this. Basically what needs to happen is V needs to note any memory segments that refer to devices and not to prod around in those areas during leak checks. That's what Jeremy's original implementation did and I guess it worked for him. The real problem is I don't have a machine with relevant card+driver on which I can implement/test a fix. Aside from that I'd be happy to give it a go. J > > IIRC, that bug was fixed in earlier versions but > > then became "unfixed" a bit > > later, unfortunately. > > > >From what I see at the mailing list, it seems like > > very few people use Valgrind together with ATI > drivers, so I'm wondering if this bug is considered > worthy of being fixed, or if it's given low priority. > The fact that both 3.1.0 and 3.2.0 have the bug make > me suspect there's no input about this from the user > base... > > In the meantime, I suppose I can use Valgrind except > for leaks, and another tool for leaks (because it > seems memory leak detection is the only memcheck > option that freezes the system). > > asiga > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2006-07-20 17:48:42
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> I don't think it would be hard to fix this. Basically what
> needs to happen is V needs to note any memory segments that
> refer to devices and not to prod around in those areas during
> leak checks. That's what Jeremy's original implementation did
> and I guess it worked for him.
Like this you mean:
Index: memcheck/mc_leakcheck.c
===================================================================
--- memcheck/mc_leakcheck.c (revision 5983)
+++ memcheck/mc_leakcheck.c (working copy)
@@ -759,6 +759,9 @@
tl_assert(seg);
if (seg->kind != SkFileC && seg->kind != SkAnonC)
continue;
+ if (seg->kind == SkFileC &&
+ (VKI_S_ISCHR(seg->mode) || VKI_S_ISBLK(seg->mode)))
+ continue;
if (!(seg->hasR && seg->hasW))
continue;
if (seg->isCH)
That essentially implements the same behaviour as before, although
in a slightly different way. I do also have a patch that creates a
new SkDevC segment type but I'm not sure it's worth bothering.
The only problem I see with this is that if you explicitly mmap
from /dev/zero to get memory (rather than using MAP_ANONYMOUS) then
it won't be checked. That problem exists with the old solution as
well though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2006-07-20 23:50:28
|
On Thu, 20 Jul 2006, Tom Hughes wrote: > In message <200...@ac...> > Julian Seward <js...@ac...> wrote: > >> I don't think it would be hard to fix this. Basically what >> needs to happen is V needs to note any memory segments that >> refer to devices and not to prod around in those areas during >> leak checks. That's what Jeremy's original implementation did >> and I guess it worked for him. > > Like this you mean: > > Index: memcheck/mc_leakcheck.c > =================================================================== > --- memcheck/mc_leakcheck.c (revision 5983) > +++ memcheck/mc_leakcheck.c (working copy) > @@ -759,6 +759,9 @@ > tl_assert(seg); > if (seg->kind != SkFileC && seg->kind != SkAnonC) > continue; > + if (seg->kind == SkFileC && > + (VKI_S_ISCHR(seg->mode) || VKI_S_ISBLK(seg->mode))) > + continue; > if (!(seg->hasR && seg->hasW)) > continue; > if (seg->isCH) > > That essentially implements the same behaviour as before, although > in a slightly different way. I do also have a patch that creates a > new SkDevC segment type but I'm not sure it's worth bothering. > > The only problem I see with this is that if you explicitly mmap > from /dev/zero to get memory (rather than using MAP_ANONYMOUS) then > it won't be checked. That problem exists with the old solution as > well though. Asiga, can you try this patch and tell us if it fixes the problem? Thanks. Nick |
|
From: Julian S. <js...@ac...> - 2006-07-21 10:33:37
|
> Like this you mean:
>
> Index: memcheck/mc_leakcheck.c
> ===================================================================
> --- memcheck/mc_leakcheck.c (revision 5983)
> +++ memcheck/mc_leakcheck.c (working copy)
> @@ -759,6 +759,9 @@
> tl_assert(seg);
> if (seg->kind != SkFileC && seg->kind != SkAnonC)
> continue;
> + if (seg->kind == SkFileC &&
> + (VKI_S_ISCHR(seg->mode) || VKI_S_ISBLK(seg->mode)))
> + continue;
Cool. I didn't know that aspacem already has the info to hand.
Asiga, does this solve the problem for you?
> The only problem I see with this is that if you explicitly mmap
> from /dev/zero to get memory (rather than using MAP_ANONYMOUS) then
> it won't be checked.
We could check the name too, I guess:
/* Don't poke around in device segments as this may
cause hangs. Exclude /dev/zero so as to check in there
just in case someone allocated memory by explicitly
mapping /dev/zero. */
if (seg->kind == SkFileC &&
(VKI_S_ISCHR(seg->mode) || VKI_S_ISBLK(seg->mode))) {
HChar* dev_name = VG_(am_get_filename)( seg );
if (dev_name && 0 == VG_(strcmp)(dev_name, "/dev/zero")) {
/* don't skip /dev/zero */
} else {
/* skip this device mapping */
continue;
}
}
J
|