|
From: Simon G. <sim...@ma...> - 2009-07-12 22:18:33
|
On Jul 12, 2009, at 2:02 PM, tom fogal wrote:
> Simon Gornall <sim...@ma...> 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
|