How/where to report MS bugs?
-
Chris Maunder wrote: Just send Nick all your bugs (VS.NET related, .NET framework related, your homework questions...). The more the merrier. Ooh, Nick's gonna get you for that one. Don't forget his blackmail threat in this month's column! Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Yes and here is my call stack:
mscorlib.dll!System.Runtime.InteropServices.Marshal::Copy(__int32 source = 0, unsigned char[] destination = {Length=0},
__int32 startIndex = 0, __int32 length = 0) + 0x26 bytessystem.drawing.dll!System.Drawing.Imaging.PropertyItemInternal::get_Value() + 0x3d bytes
system.drawing.dll!System.Drawing.Imaging.PropertyItemInternal::ConvertFromMemory(__int32 propdata = 1541584,
__int32 count = 49) + 0x100 bytessystem.drawing.dll!System.Drawing.Image::get_PropertyItems() + 0xe6 bytes
Clearly 0 is being passed as an argument to Marshal::Copy(). There is some check is missing for IntPtr == null... Chris M. is going to ban us forever for posting all this programming stuff in the lounge... :-O
Here is the code for get_Value() :
public byte[] get_Value() {
byte[] local0;local0 = new Byte\[checked((uint) this.len)\]; Marshal.Copy(this.value, local0, 0, this.len); return local0;}
Marshal.Copy does a simple low-level buffer copy, without ptr checking. That's the reason why there is the exception. In this case, both src ptr (null) and dest ptr (result of new [0], thus null) are wrong. Here are the actual members of the PropertyItemInternal class :
int id;
int len;
short type;
IntPtr value;Now when you see what ConvertFromMemory does (it creates PropertyItemInternal instances from an input propdata structure), the problem comes from either of these : - you are accessing a non-existing propertyiteminternal - propdata is actually empty (file decoding completely or partially failed due to bad format). As a conclusion, this issue is not related to the .NET framework. Yes, MS could check the ptrs before they Copy memblocks. But in the end, it's more about you using the GDI+ API for an unknown file format.
She's so dirty, she threw a boomerang and it wouldn't even come back.
-
Here is the code for get_Value() :
public byte[] get_Value() {
byte[] local0;local0 = new Byte\[checked((uint) this.len)\]; Marshal.Copy(this.value, local0, 0, this.len); return local0;}
Marshal.Copy does a simple low-level buffer copy, without ptr checking. That's the reason why there is the exception. In this case, both src ptr (null) and dest ptr (result of new [0], thus null) are wrong. Here are the actual members of the PropertyItemInternal class :
int id;
int len;
short type;
IntPtr value;Now when you see what ConvertFromMemory does (it creates PropertyItemInternal instances from an input propdata structure), the problem comes from either of these : - you are accessing a non-existing propertyiteminternal - propdata is actually empty (file decoding completely or partially failed due to bad format). As a conclusion, this issue is not related to the .NET framework. Yes, MS could check the ptrs before they Copy memblocks. But in the end, it's more about you using the GDI+ API for an unknown file format.
She's so dirty, she threw a boomerang and it wouldn't even come back.
__Stephane Rodriguez__ wrote: But in the end, it's more about you using the GDI+ API for an unknown file format. Yes and no. Format is not unknown and it was not like a change from EXIF ver. 1 to version 2 it was from 2.1 to 2.2. Beside that, some EXIF 2.2 files are read without a problem and I have just find out that people have seen the same problem with some of the older versions of EXIF as well. Now, that fact that it is not in .NET framework per se, but in underlying GDI+ makes it even more of a problem, because now it's not only affecting managed code developers and apps, but anybody who is using GDI+ including unmanaged C++ scenarios. I have reported this problem in one of the MS newsgroups last night. One of MS employees replied and asked for sample image. I have provided them with sample image and I am still waiting to hear back from them. In the mean time 2 or 3 other guys have reported that they have been experiencing the same problem together with couple of workarounds. I'll keep you posted. Thank you for looking into it. Kostya.
-
__Stephane Rodriguez__ wrote: But in the end, it's more about you using the GDI+ API for an unknown file format. Yes and no. Format is not unknown and it was not like a change from EXIF ver. 1 to version 2 it was from 2.1 to 2.2. Beside that, some EXIF 2.2 files are read without a problem and I have just find out that people have seen the same problem with some of the older versions of EXIF as well. Now, that fact that it is not in .NET framework per se, but in underlying GDI+ makes it even more of a problem, because now it's not only affecting managed code developers and apps, but anybody who is using GDI+ including unmanaged C++ scenarios. I have reported this problem in one of the MS newsgroups last night. One of MS employees replied and asked for sample image. I have provided them with sample image and I am still waiting to hear back from them. In the mean time 2 or 3 other guys have reported that they have been experiencing the same problem together with couple of workarounds. I'll keep you posted. Thank you for looking into it. Kostya.
Konstantin Vasserman wrote: because now it's not only affecting managed code developers and apps, but anybody who is using GDI+ including unmanaged C++ scenarios. If MS provides an interim gdiplus.dll release, then it will work in C++ AND .NET without updating .NET
She's so dirty, she threw a boomerang and it wouldn't even come back.
-
Konstantin Vasserman wrote: because now it's not only affecting managed code developers and apps, but anybody who is using GDI+ including unmanaged C++ scenarios. If MS provides an interim gdiplus.dll release, then it will work in C++ AND .NET without updating .NET
She's so dirty, she threw a boomerang and it wouldn't even come back.
True. There are always pros and cons to everything... ;)