search

mbraceproject / FsPickler

A fast multi-format message serializer for .NET
http://mbraceproject.github.io/FsPickler/
MIT License
326 stars 52 forks source link

Types serialized by 32bit process cause 'stream error' when deserialized by 64bit process in v 0.51 #2

Closed kjnilsson closed 11 years ago

kjnilsson commented 11 years ago

Hi - I have tested this fairly thoroughly (v 0.5.1) and it appears to be consistently failing in the above scenario. I tested it against a build of the current master and the issue appears to be gone. Would you mind releasing a new nuget package?

eiriktsarpalis commented 11 years ago

Hey,

I've never really tested this, so the issue has either been inadvertently fixed or it may have something to do with the nuget build. In a more general note, you should keep in mind that the library does not support interconnectivity between heterogeneous runtimes, so mono/.net or even differing clr versions cannot communicate. That said, I'll see if I can obtain a 32 bit machine to test this out.

kjnilsson commented 11 years ago

here is a test solution that repros the issue: https://dl.dropboxusercontent.com/u/5434569/FsCoreBug.zip The FsCoreBug console app will write a file as a 32bit process (prefer 32 bit set in project preferences). FsCoreBug64 will try to read it.

kjnilsson commented 11 years ago

you can run this on a 64 bit machine. I have also included the actual data files created by a 32 (fscorebug32.dat) and 64 bit (fscorebug.dat) process respectively.

kjnilsson commented 11 years ago

And thank you, btw. :)

eiriktsarpalis commented 11 years ago

The bug still exists in the current version of the serializer, but it only occurs with release builds of the library.

kjnilsson commented 11 years ago

Right ok - yes I only tested in Debug - how odd. It's quite easy to see which bytes are different but I am not sure what writes them (and why it doesn't write them in Debug mode)

eiriktsarpalis commented 11 years ago

Fixed. Problem had to do with the fact that certain type hashes are written at every object header. These hashes were being generated using the .GetHashCode() method on assembly qualified names. As it turns out, different versions of the clr generate different hashcodes for strings.

I will update the nuget package asap.

kjnilsson commented 11 years ago

Awsome work. Tested it with my application and it works fine. Many thanks.

jackfoxy commented 11 years ago

I repeatedly warned one of our programmers not to use GetHashCode() for persisted hashes (even the MS documentation indicated against this). Of course he did not listen, and I believe the breaking change was from .NET 2.0 to 3.0 (or possibly 3.5).