Andy22 Posted March 13, 2014 Report Share Posted March 13, 2014 I tested plastic on freeBSD 9.2 x32/x64 and inside the respective jails. (NOTE: Using a 32bit freeBSD or 32bit nas4free base system works without problems. [UPDATE: freeBSD 10 x64 works too!) For some reason Plastic5 gives this error on a Win7 x64 client trying to checkin to a x64 freeBSD 9.2 host server system, using SQLite3 as DB. "Binary stream '0' does not contain a valid Binary Header. Possible causes are invalid stream or object version change between serialization and deserialization." I suspect this is some form if incompatible zlib stream?byeAndy Link to comment Share on other sites More sharing options...
manu Posted March 17, 2014 Report Share Posted March 17, 2014 Hi Andy, (NOTE: Using a 32bit freeBSD or nas4free base system works without problems.) Thanks for the info. Yes it seems and issue with the zlib library, can you test to remove the one we are deploying and compiling the right one for FreeBSD? Maybe the OS is having it's own one so it will be interesting just removing ours and testing the operation. Link to comment Share on other sites More sharing options...
Andy22 Posted March 17, 2014 Author Report Share Posted March 17, 2014 Hi Andy, Thanks for the info. Yes it seems and issue with the zlib library, can you test to remove the one we are deploying and compiling the right one for FreeBSD? Maybe the OS is having it's own one so it will be interesting just removing ours and testing the operation. Like i noted in my freeBSD tutorial, under freeBSD/linux the zlib.dll is ofc never used, so is any other native windows dll. Thats why the SQLite ADO dll on linux/freeBSD always uses the sqlite/zlib from the system and not the windows dll. I also physically deleted the zlib.dll's. I did compile a 64bit zlib from the current source, but since zlib is part of the freeBSD kernel, i cant verify if the kernel or compiled library "libz.so" was actually used. bye Andy PS: I'm also confused, the "PlasticSCM-5.0.44.537-linux-server-binaries.zip" which is the same for windows, still has all those native compiled windows dll's, which by my understanding will never run under Linux/freeBSD even if mono is used? I was under the impression that the native code that a .net file can dynamically load, must be compiled specifically for the target system, since its native code? So u can wrap native windows x32/x64 code in a managed file, as the sqlite ADO .dll does. What u can't do is also put the linux library in it, since the system to load/execute/package native code is different, between linux/windows? Link to comment Share on other sites More sharing options...
psantosl Posted March 17, 2014 Report Share Posted March 17, 2014 Hi, The problem is not with any of the dlls. We are not using any managed dlls to zip or unzip. On Linux you'll have some sort of zlib.so, this is what you need to replace. We've tested Plastic on FreeBSD in the past and it works fine, we passed the entire testsuite there without any problems. My goal is to add a FreeBSD box to the list of machines we use on a daily basis to test plastic. Link to comment Share on other sites More sharing options...
Andy22 Posted March 18, 2014 Author Report Share Posted March 18, 2014 Hi, The problem is not with any of the dlls. We are not using any managed dlls to zip or unzip. On Linux you'll have some sort of zlib.so, this is what you need to replace. We've tested Plastic on FreeBSD in the past and it works fine, we passed the entire testsuite there without any problems. My goal is to add a FreeBSD box to the list of machines we use on a daily basis to test plastic. FreeBSD 9.2 has the "libz.so" installed by default, its actually the "libz.so.6" which is 1.2.3/4 ? No idea how to read the version from the .so file. Plastic looks for the "libz.so" so we should be able to test new compiled versions. Btw i'm a little curious on why u don't use the "ICSharpCode.SharpZipLib" version? This should remove the additionally native dependency for zlib on all target platforms? Is the c# lib to slow compared to the native version? thx Andy PS: I would recommend u do a quick testrun on a x64 9.2 -p3 freeBSD inside a VM and see for yourself, since i don't get any extended logs regarding this error. Btw would also be nice to get the freeBSD script changes applied, so it works out of the box. Link to comment Share on other sites More sharing options...
Andy22 Posted March 18, 2014 Author Report Share Posted March 18, 2014 [update] Just tested inside a 64bit freeBSD 10 VM and there it works fine. So it seems to-be a isolated problem on freeBSD 9.2, which is unfortunate since nas4free and freeNAS both base on freeBSD 9.2 and if u want to use ZFS u need >=8 GB ram, which only the x64 version supports. Its rather unfortunate that out of all combinations the most interesting combination (nas4free/freeNAS x64 + ZFS) is bugged atm, hopefully this can be fixed? bye Andy PS: I also just did a fresh install of 9.2-x64 using the exact same files/conf from the working freeBSD 10-x64 install, but still get the same error. So its a freeBSD 9.2 x64 problem, u should be able to reproduce quickly in a VM. Link to comment Share on other sites More sharing options...
Andy22 Posted March 18, 2014 Author Report Share Posted March 18, 2014 Maybe this is not zlib related at all? I tried several combinations on the 9.2 install: 1) org. zlib64.dll on client and org. freeBSD 9.2 "zlib.so.6" (64 bit, 1.2.4) on server = fail (at check-in error or workspace creation) 2) org. zlib64.dll on client and org. working freeBSD 10 "zlib.so.6" (64 bit, 1.2.4) on server = fail (at check-in error or workspace creation) 3) org. zlib64.dll on client and self compiled 1.2.8 "zlib.so" (64 bit, 1.2.8) on server = fail (at check-in error or workspace creation) 4) self compiled zlib64.dll (1.2.8) on client and self compiled "zlib.so" (1.2.8) on server = fail (at check-in error or workspace creation) So i'm out of options to fix this problem myself... bye Andy Link to comment Share on other sites More sharing options...
psantosl Posted March 25, 2014 Report Share Posted March 25, 2014 Btw i'm a little curious on why u don't use the "ICSharpCode.SharpZipLib" version? This should remove the additionally native dependency for zlib on all target platforms? Is the c# lib to slow compared to the native version? Hey Andy, We do not use SharpZipLib because it is consistently slower than the native zlib code. Link to comment Share on other sites More sharing options...
psantosl Posted March 25, 2014 Report Share Posted March 25, 2014 Andy, What Mono versions are you using?? Thanks, pablo Link to comment Share on other sites More sharing options...
Andy22 Posted March 25, 2014 Author Report Share Posted March 25, 2014 Andy, What Mono versions are you using?? Thanks, pablo It was 3.2.8 or 3.2.7 Link to comment Share on other sites More sharing options...
psantosl Posted March 25, 2014 Report Share Posted March 25, 2014 Ok, I'll try to give it a try with 9.2 Link to comment Share on other sites More sharing options...
Andy22 Posted September 18, 2014 Author Report Share Posted September 18, 2014 Was this ever fixed, u did not report back on this issue? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.