#220 Heap corruption on ChoosePixelFormat?

[immuner]

Hello,

I have been using application verifier to check for heap corruption issues on my application. It seems to break at the fgSetupPixelFormat->ChoosePixelFormat function. This has been identified only on my AMD GPU not on any of my Nvidia ones. However, I am not sure whether this is an actual freeglut issue.

System settings:
Platform: Windows 7 64-bit
GPU: AMD R290X
GPU drivers: latest (14.12)

Code settings:
glutInitWindowSize(500, 250);
glutInitWindowPosition (140, 140);
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_SRGB);
glutInit(&argc, argv);
glutCreateWindow("test");

Test settings:
Tested on the fractals demo using MSVC 2013 and Debug_Static_x64. This issue occurs on other applications as well, however this is the simplest example i found.

Regards

[Diederick C. Niehorster]

Hi,

Thanks for the report! I have looked through our code for that
function, and there is no potential for such problems at that location
from our side. No dynamic arrays or anything around there. So this
probably is a driver issue, especially given that it only shows up for
AMD cards.

Thanks,
Dee

On Fri, Mar 20, 2015 at 12:53 PM, immuner immuner@users.sf.net wrote:

---

[bugs:#220] Heap corruption on ChoosePixelFormat?

Status: open
Group:
Created: Fri Mar 20, 2015 11:53 AM UTC by immuner
Last Updated: Fri Mar 20, 2015 11:53 AM UTC
Owner: nobody

Hello,

I have been using application verifier to check for heap corruption issues on my application. It seems to break at the fgSetupPixelFormat->ChoosePixelFormat function. This has been identified only on my AMD GPU not on any of my Nvidia ones. However, I am not sure whether this is an actual freeglut issue.

System settings:
Platform: Windows 7 64-bit
GPU: AMD R290X
GPU drivers: latest (14.12)

Code settings:
glutInitWindowSize(500, 250);
glutInitWindowPosition (140, 140);
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_SRGB);
glutInit(&argc, argv);
glutCreateWindow("test");

Test settings:
Tested on the fractals demo using MSVC 2013 and Debug_Static_x64. This issue occurs on other applications as well, however this is the simplest example i found.

Regards

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freeglut/bugs/220/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[John Tsiombikas]

So, should we close this bug?

[immuner]

Hello,

thank you for your reply. I assume it is most likely a driver issue, however i thought it would be best to mention it so that you can keep it on the back of your minds. What actually happens is that on a 5-10% of the times i start my application, it will show corrupted data and I would have to restart it.
If you were not able to reproduce it on a similar amd card or there is no probable reason this is a freeglut issue then i will simply have to wait for an updated driver version to check if it has been corrected. As i mentioned before, there is no problem on any of my nvidia gpus.

Thank you again

[Diederick C. Niehorster]

Hi,

On Wed, Apr 1, 2015 at 1:40 AM, immuner immuner@users.sf.net wrote:

What actually happens is that on a 5-10% of the times i start my application, it will show corrupted data and I would have to restart it.

That sounds more serious. Would you be able to debug this further, see
if it is the call to ChoosePixelFormat that causes this, or if it
simply leads to an attempt to access already corrupted memory? And
perhaps then, with a memory location breakpoint, determine where this
corruption happens?

Otherwise i am afraid there is little we can do. Though it does seem
that it is a driver bug. My AMD 4750 (or something like that, higher
4000 series) did not show this issue.

Best,
Dee

[John Tsiombikas]

Please post a minimal example program which reproduces this problem, so we can properly test this. If you can't reproduce this problem outside of your original application, it's probably your code which causes heap corruption and it happens to fail when calling ChoosePixelFormat by accident. Either way please let us know so we can close the bug if it's not reproducible.