How can we help you today? How can we help you today?

Bug Report - Reflector producing incorrrect source code

It took me hours of wasted productivity to figure out this.
I have uploaded the FJ.Core assembly on rapidshare
http://rapidshare.com/files/180970796/FJ.Core.dll.html

Basically, I was trying to reverse engineer it.
This is a Silverlight 2 assembly that does NOT have a dependency on anything except the core SL assemblies.

Have a look at the following method:
FluxJpeg.Core.Decoder.JpegDecoder.Decode() method.

The return type of this method if DecodedJpeg from the same assembly.
The reverse-engineered source code shows only 2 return statements in this method both returning null. There is no other return statement shown by the disassembled code. That effectively means that it would always return null.

When I reverse-engineered this whole assembly yo generate source code, and then compiled this assembly myself, this method turned into an infinite loop (while(true))
Thus, my SL app using the reverse engineered code was stuck in an infinite loop.

However, when I referenced the original assembly, this method worked fine without any changes.
That effectively means there is some problem with the decompiled code. I have no idea what.

Have a look at the following entry to see how this method is to be used:
http://www.jeff.wilcox.name/2008/07/fjcore-source/
r_honey
0

Comments

2 comments

Sort by
  • TigerShark
    Yeah, that definitely looks strange, however the IL does seem to produce the correct result (3 return statements). If you turn off the optimizations in the options dialog, you'll also find 3 return statements, but when optimization is on, it's reduced to only 2 (kinda funny way to optimize - don't return anything ;) ).

    Can't really say what the problem is other than it could be some sort of mess up with the huge switch statement.
    TigerShark
    0
  • r_honey
    Yes, I also checked that out. Having optimizations off probably produces the correct code (with 3 returns).

    But there is almost no use of disassembling with optimizations off as the code produced is almost akin to Assembly Code as regards to Control Flow statements. And it is next to impossible to understand what's going on inside an assembly with that kind of control flow.
    r_honey
    0

Add comment

Please sign in to leave a comment.