an image passed to GdipGetImageGraphicsContext() is destroyed right after the graphics object was created, then later on all calls using that HDC fail and silently lead to using invalid or not initilazed values.
You have to keep the image alive as long as you're using the Graphics object. If you're not doing that, then you have a use-after-free and I don't trust the results of your test.
We shouldn't need to have any HDC for much longer in this case anyway. Once we have a software implementation of line-drawing (which should just be a matter of filling a path from GdipWidenPath), we can get rid of the HBITMAP and HDC on Bitmap objects.
Vincent Povirk madewokherd@gmail.com wrote:
an image passed to GdipGetImageGraphicsContext() is destroyed right after the graphics object was created, then later on all calls using that HDC fail and silently lead to using invalid or not initilazed values.
You have to keep the image alive as long as you're using the Graphics object. If you're not doing that, then you have a use-after-free and I don't trust the results of your test.
You are welcome to experiment with the test and try to prove that its results depend on the availability of an image. My tests show that image after the GdipGetImageGraphicsContext() call can be safely destroyed, and the test results don't depend on it.
an image passed to GdipGetImageGraphicsContext() is destroyed right after the graphics object was created, then later on all calls using that HDC fail and silently lead to using invalid or not initilazed values.
You have to keep the image alive as long as you're using the Graphics object. If you're not doing that, then you have a use-after-free and I don't trust the results of your test.
You are welcome to experiment with the test and try to prove that its results depend on the availability of an image. My tests show that image after the GdipGetImageGraphicsContext() call can be safely destroyed, and the test results don't depend on it.
You're adding a test that relies on a corner case that should be regarded as a broken program, and that could easily result in a use-after-free on native. I'm not convinced this is reliable, as the native codepath could involve a use-after-free and still work by coincidence. There is no evidence that any real program relies on this case, and you could easily modify your test to not depend on it.
By "fixing" this corner case, you risk breaking others. I wonder if native can have multiple Graphics objects that draw to a single Bitmap. I don't think an HBITMAP can be selected into multiple HDCs, but since native does everything through memory it could easily handle this. I don't know if any real program relies on this, but to my knowledge nothing relies on the thing you're testing either.
And as I said, the HBITMAP and HDC are both going away soon. We know native doesn't have them. So you're making minor adjustments to a stop-gap solution that we know is wrong, in order to fix code that is arguably broken and that does something no program to our knowledge does. I just don't see the point.
Vincent Povirk madewokherd@gmail.com wrote:
You're adding a test that relies on a corner case that should be regarded as a broken program, and that could easily result in a use-after-free on native. I'm not convinced this is reliable, as the native codepath could involve a use-after-free and still work by coincidence. There is no evidence that any real program relies on this case, and you could easily modify your test to not depend on it.
Do you have any proof that "it's a corner case and is not reliable"? The test passes for me in any number of runs and test sequences under 32-bit bit XP and as 32 or 64-bit executable under 64-bit Win7.
-
Dmitry Timoshkov -
Vincent Povirk