|
From: Wayne A. <Way...@au...> - 2006-07-24 16:13:40
|
> On Thu, 20 Jul 2006, Tom Hughes wrote: >=20 > > In message <200...@ac...> > > Julian Seward <js...@ac...> wrote: > > > >> I don't think it would be hard to fix this. Basically=20 > what needs to=20 > >> happen is V needs to note any memory segments that refer=20 > to devices=20 > >> and not to prod around in those areas during leak checks. That's=20 > >> what Jeremy's original implementation did and I guess it=20 > worked for=20 > >> him. > > > > Like this you mean: > > > > Index: memcheck/mc_leakcheck.c > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- memcheck/mc_leakcheck.c (revision 5983) > > +++ memcheck/mc_leakcheck.c (working copy) > > @@ -759,6 +759,9 @@ > > tl_assert(seg); > > if (seg->kind !=3D SkFileC && seg->kind !=3D SkAnonC) > > continue; > > + if (seg->kind =3D=3D 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,=20 > although in=20 > > a slightly different way. I do also have a patch that creates a new=20 > > SkDevC segment type but I'm not sure it's worth bothering. > > > > The only problem I see with this is that if you explicitly=20 > mmap from=20 > > /dev/zero to get memory (rather than using MAP_ANONYMOUS) then it=20 > > won't be checked. That problem exists with the old solution as well=20 > > though. >=20 > Asiga, can you try this patch and tell us if it fixes the=20 > problem? Thanks. This fixes the problem for myself, running Maya on ATI FireGL cards -- Wayne |
|
From: Julian S. <js...@ac...> - 2006-07-26 09:55:12
|
> > > 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. > > This fixes the problem for myself, running Maya on ATI FireGL cards Good. The other person who reported the same problem also reports it helps de-hang V. J |
|
From: Julian S. <js...@ac...> - 2006-07-27 23:15:57
|
I just committed a slightly modified version of this patch (as valgrind svn revision 5990). If anybody who experienced these system lockups would care to check out the svn version and try it, that would appreciated. J On Monday 24 July 2006 17:13, Wayne Arnold wrote: > > 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. > > This fixes the problem for myself, running Maya on ATI FireGL cards > > > -- > Wayne > > ------------------------------------------------------------------------- > 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 |