IDE Crash when converting C# to Oxygene

I get the following when converting any C# file to Oxygene

Value cannot be null.
Parameter name: collection
at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at force)
at RemObjects.Fire.ProjectSystem.TextFile.<>c__DisplayClass32.b__0(String code)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Thanks, logged as bugs://82926

@mh This is the current issue with Oxidizer… happy to work through this with you as a good test project to convert

I don’t see this with “any” file, and I use this quite frequently. can you send me a concrete file that fails?

Ok so wanted to send you the zlib library as a test case for this issue as this is what I was wanting to convert to Oxygene. This complied and ran fine but now crashes when running under Water 2433 in DEBUG mode with…

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Compiles and runs just fine in RELEASE mode.
I suspect the above issue needs to be another ticket…

The C# to Oxygene issue. On the attached project right click on any C# file (eg Deflate.cs) and select convert to Oxygene. The IDE will then crash

Zlib (2.5 MB)

Odd. the Oxidixer issue does’t repro in Fire, I’ll need to have someone check in Water, tomorrow. Same for the actual runtime issue. This crash is new, as in it ran fine in a prior Elements version?

Thanks, logged as bugs://83149

Yep, worked in debug mode in prior versions… want me to downgrade and try it ?

I’m getting;

~> Process Zlib Island test started
The magic happens here.
String ticks: 637024843750020 Size: 338925
Stringbuilder ticks: 70 Size: 338925
about to compress
String 338925
Array  22897
!> Additional exception of type Ionic.Zlib.ZlibException on thread 58C4
!> Message: 

#> (edb) 

Not an access violation. It seems to originate from here:

                                if (i + j > 258 + (t & 0x1f) + ((t >> 5) & 0x1f) || (c == 16 && i < 1))
                                    blens = null;
                                    mode = InflateBlockMode.BAD;
                                    _codec.Message = "invalid bit length repeat";
                                    r = ZlibConstants.Z_DATA_ERROR;

                                    bitb = b; bitk = k;
                                    _codec.AvailableBytesIn = n;
                                    _codec.TotalBytesIn += p - _codec.NextIn;
                                    _codec.NextIn = p;
                                    writeAt = q;
                                    return Flush(r);
Name Value Type
i + j 387 Integer
258 + (t & 0x1f) + ((t >> 5) & 0x1f) 303 Integer

If I store the data and decompress it with a known working gzip implementation from ionic on .net I get the exact same error. So something goes wrong in compressing it seems.

From byte 19 on things seems to be wrong.

Works ok when in release mode for you ?

No. It fails in both for me (after a rebuild)

Down to
internal void build_tree(DeflateManager s)

It goes wrong in there.
// Update 1: Fine up to node = elems; // next internal node of the tree

// Update2: snip

// Update 3: gen_bitlen inside build_tree seems to mangle it.

// Update 4: found it; this tree[n * 2] = ((short) (bi_reverse(next_code[len]++, len)));

somehow returns the incremented value of next_code[len], not the original.

bugs://83149 got closed with status fixed.

bugs://82926 got closed with status fixed.

Can confirm C# to Oxygene conversion now works

1 Like

Hi Carlo,
Sorry have been away so only just back to this… on latest build 2437 actual issue (Oxidizer crash converting C# to Oxygene) is fixed :slight_smile:

Compile and execution of zlib test - in release 100% ok. in debug now just fails. Was not sure what you had… eg update 4 is valid so issue with original zlib source ?


hrmm I was sure I had it working in both when I last tested it (but must admit it’s been a while). which zip should I try again? There’s no bug in zlib like that as far as I can tell :slight_smile: it’s going to be in the compiler if it miscompiles.