I've just checked in some major changes in order to track down a heap
corruption on Win32, to no avail.
I will be very grateful if you can have an attempt to find the
problem. The corruption occurs upon exit in eqPly and eVolve in Debug
builds when the eqPly/eVolve object is destroyed.
My last change (3056) did:
- set all projects to Multithreaded DLL (/MD instead of /MT)to avoid
issues with separate DLL heaps
- increase warning level to 2 and fix the resulting warnings (mostly
dll export issues)
Feel free to get back to me via private email (english, german,
french) if you feel more comfortable that way.
Best,
Stefan.
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Hey,
I confirm the heap corruption. I'll take a look on the code..
Regards,
Adam
--
View this message in context: http://n2.nabble.com/Win32-help-needed-tp3055141p3058738.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
On Wednesday 10 June 2009 13:55:20 Stefan Eilemann wrote:
> I've just checked in some major changes in order to track down a heap
> corruption on Win32, to no avail.
>
> I will be very grateful if you can have an attempt to find the
> problem. The corruption occurs upon exit in eqPly and eVolve in Debug
> builds when the eqPly/eVolve object is destroyed.
>
> My last change (3056) did:
>
> - set all projects to Multithreaded DLL (/MD instead of /MT)to avoid
> issues with separate DLL heaps
> - increase warning level to 2 and fix the resulting warnings (mostly
> dll export issues)
Did you already run the eqPly through valgrind? I did that here and it
uncovered quite a few errors, also some errors upon exit. Those might lead to
crashes in some circumstances.
However, I'm still using Equalizer 0.6, so these problems might be fixed in
the meantime.
The valgrind log from running eqPly is attached.
Regards,
Thomas
> Did you already run the eqPly through valgrind?
Yes :)
> I did that here and it
> uncovered quite a few errors, also some errors upon exit. Those
> might lead to
> crashes in some circumstances.
With trunk, there are a few errors in third-party libraries, and a few
harmless 'uninitialized read' during packet sends, which are ok
because the data in question is never read on the other side.
Thanks,