- January 25, 2012 at 1:12 pm #30738
I’m expecting random crash inside pvrtc.lib.
Please download this test project to reproduce the problem:
Source code included.
Its crashing on Windows 7 x86, Core 2 Duo CPU.
SDK version: 2.09.29.0649
Andrew.January 26, 2012 at 10:41 am #35386
It seems you have the first release version of the pvrtc library (it’s still packaged in the SDK unfortunately). If you go to the PVRTexLib utility page (here: https://www.imgtec.com/powervr/insider/powervr-pvrtexlib.asp) and download the version of PVRTC from there, the latest version should fix your issue. I tested your app with both the version you packaged and the version from the utilities page and the latest version did not crash after 100 iterations.
TobiasJanuary 26, 2012 at 11:43 am #35387
Thank you so much for reply!
Unfortunately its still crashing with another input data.
Check out this version:
Andrew.January 26, 2012 at 2:05 pm #35388
As far as I can tell, this only happens when running a debug build against the library. If you define NDEBUG in the pre-processor, everything should work without a problem. If you’re finding this problem with Release builds of your app (and are defining NDEBUG there too) then let me know.
TobiasJanuary 26, 2012 at 2:48 pm #35389
I think NDEBUG is not a solution here. In my opinion pvrtc.lib corrupts memory in some random location. Because address of that location is unpredictable it may depend on many aspects of compilation like Release/Debug, optimization flags & etc.
You may try to run pvrtc compressor under valgrind. Its a great tool to resolve such kind of problems.
UPDATE: It crashed in Release build too.
Andrew.January 26, 2012 at 3:17 pm #35390
The problem that I was seeing is caused because some of the compressor code is calling “assert” at various points for debugging. In release mode this assert is defined to do nothing. However it looks as if not defining NDEBUG causes the assert to still happen.
In this particular instance it seems that an assert(0) has been left in the code, which is a bug that I’m going to raise with the engineer responsible so that it doesn’t cause problems in future. So NDEBUG, whilst not ideal, seems to be the only workaround for this problem at the moment.
Are you also getting a crash in Release mode, against the latest library, and with NDEBUG specified? If so, this is a separate bug which I also need to look into, are you getting any useful output in the call stack?
TobiasJanuary 26, 2012 at 4:26 pm #35391
Because I’m using precompiled library, defining NDEBUG macro doesn’t affect the library in any manner.
Yes, I’m getting crash in Release mode, against the latest library and with NDEBUG specified.
I’m almost sure that the reason of the crash in the test project I provided before is the same as in the release build of my texture packer.
mad_rain2012-01-26 16:29:42January 27, 2012 at 9:56 am #35392
I apologise, assert is part of the VS library and I thought its function was defined in a specific object rather than a header, and linked in at the end after PVRTexLib (thus my thinking about the NDEBUG define). I can see now that this is not the case!
So it sounds like I’ve been unable to reproduce your bug so far with the new libs, however I’m going to set your test running over the weekend to see what happens. Hopefully I’ll find something! I would mention that we’ve recently discovered a thread handle leak problem in the PVRTC encoder, I’m not sure if that would be causing the problem, but it could be; I’ll let you know what I find. How long is it before you typically see a crash?
TobiasJanuary 27, 2012 at 11:33 am #35393
The test project usually crash at its first iteration or not crashing at all. Please try to launch it several times, you might not get crash just by waiting for more iterations.
Andrew.January 27, 2012 at 11:50 am #35394
Hmm, interesting. I’ll write a batch file to continuously launch it and kill it then.January 27, 2012 at 12:19 pm #35395
Here disassembly of crash location (pvrtc_crash2.zip). I’m not providing call stack because it looks useless.
Crashing probability near to 50%.
I’m a little surprised how many threads you use and how many times you call malloc/free.
EAX = 000AFFF8 EBX = 00000000 ECX = 000AD708 EDX = 000AD528
ESI = 000AD780 EDI = 00000000 EIP = 00111872 ESP = 1092FC2C
EBP = 00000004 EFL = 00010202
00111855 F2 0F 58 C1 addsd xmm0,xmm1
00111859 F2 0F 5A E8 cvtsd2ss xmm5,xmm0
0011185D 8B C8 mov ecx,eax
0011185F F3 0F 10 08 movss xmm1,dword ptr [eax]
00111863 F3 0F 5A 44 24 24 cvtss2sd xmm0,dword ptr [esp+24h]
00111869 0F 5A C9 cvtps2pd xmm1,xmm1
0011186C 66 0F 2F C1 comisd xmm0,xmm1
00111870 76 11 jbe 00111883
>>> 00111872 F3 0F 10 48 28 movss xmm1,dword ptr [eax+28h]
00111877 83 C0 28 add eax,28h
0011187A 0F 5A C9 cvtps2pd xmm1,xmm1
0011187D 66 0F 2F C1 comisd xmm0,xmm1
00111881 77 EF ja 00111872
00111883 3B C8 cmp ecx,eax
00111885 0F 84 87 00 00 00 je 00111912
0011188B E8 40 FD FF FF call 001115D0
00111890 F2 0F 10 0D E8 D5 18 00 movsd xmm1,mmword ptr [__real@3fe4000000000000 (18D5E8h)]
Please let me know if you need some help from me.
mad_rain2012-01-27 12:20:48January 28, 2012 at 10:50 pm #35396
I can confirm the pvrtc.lib is flawed – for me it crashed too.The latest PVRTexLib also unusable due to crashes (on high quality mode).January 30, 2012 at 11:37 am #35397
I’m still having difficulty replicating your bug, I’ve got it to crash just once so far, even then it did so cleanly. Do you still get this issue after a restart? I’m starting to be more and more suspicious that it is to do with the thread handle leakage. If you could try restarting and running the test again it to see if this (temporarily) fixes the issue it would be very helpful. I can probably send out a version with the thread handle leak fix if this works.
TobiasJanuary 30, 2012 at 11:40 am #35398
If you’re using the latest version as well then you could be experiencing a similar issue. Could you also try doing a restart and see if this fixes your problem on the first few runs?