On Jul 12, 2009, at 2:02 PM, tom fogal wrote:
Simon Gornall <[email protected]> writes:
I'm trying to run my application under valgrind, and it's failing
when I initialise the OpenGL context... I get the debug log:
To clarify -- are you saying that it can initialize the context fine
when run standalone, and only fails through valgrind?
Well, the application runs fine without valgrind, and I have no reason
to suspect it doesn't work - the GL output is as-expected. It may well
be that there is a problem in the nVidia drivers, but it's not causing
any application-level problems :)
(I'm going to assume `yes'... sorry.)
==50304== ... (snipped)
==50304== Process terminating with default action of signal 11
(SIGSEGV)
==50304== Access not within mapped region at address 0x187E7108
==50304== at 0x1466316: memcpy (mc_replace_strmem.c:482)
==50304== by 0x16050DFA: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
[snip]
I've been playing with suppressions because the above are OS-internal
issues, and eventually (after failing to stop the SIGSEGV being
sent),
my 'valgrind' file looks like:
-----8<-----8<----- Snip here -----8<-----8<-----
{
GL context creation
Memcheck:Addr16
fun:memcpy
...
fun:CGLCreateContext
}
[snip]
I started off with more-specific suppressions, but even with the
above, the application is aborted every time I run.
This sentence implies you are slightly confused about the semantics of
a suppression file. These files are merely to suppress *reporting* of
errors; the existance or not of any given suppression should not
change
the behavior of a program. It will certainly change what valgrind
prints out, but not what's going on under the hood.
Ah - yes, I was hoping it was more along the lines of "yes, I know
there's an issue there, just ignore it for now". I take it there's no
way of doing that, then ?
Since you're using nvidia's driver, I'd ask you to re-run using the
command line option `--smc-check=all'. I am not as familiar with
nvidia's Mac driver, but on Linux the driver utilizes self modifying
code, which causes me to see a lot of errors similar to the one you
describe above. Note that even with SMC checking, I still see a lot
of
nvidia-based errors, so don't expect this will be a 100% solution.
Yep, it fails in the same way.
If that fails, I suggest linking your program against Mesa, probably
mangled Mesa for logistical reasons. That will valgrind much more
`nicely'. This:
http://visitusers.org/index.php?title=Mangled_Mesa
might help you, if you need to go that route.
Thanks, I'll see if that helps - the application uses CoreImage (and
therefore a lot of GPU shader code) quite heavily though, so I'm not
sure if Mesa is up to it (I haven't used it in a decade or so, so I
might be unfairly maligning Mesa :)
Hmm - actually I think I could force the use of the software-renderer
within CoreImage, which would slow the app down a lot, but might get
me past this...
ATB,
Simon
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
