Which version of CLIPS are you using? Where did you get it from? Which operating system are you using? Which compiler did you use? What is the contents of the xy.clp file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, sorry for missing the parameters. It is v6.30 checked out from this SVN couple of months ago (I watched the changes but I did not find any related). I use a MS Visual studio 2010 (I could even send the project). I do a test in which a text Clips program is generated (no COOL features), then a batch is created (as described) and run as (batch-star ). The test is run from a .NET environment but the named operations are called within a batch.
When the test is run against a CLIPS DLL compiled for a Win32 architecture (and under WOW64 - 32bit mode), everything is OK. When the identical test is run against a CLIPS DLL compiled for a x64 architecture and in a true 64 bit mode, the (bload ) fails for a memory corruption. I found one inconsistency between bload and bsave sequence of IO operations but currently I am stuck on bloading handles for a module. I even dumped the IO operations in both modes when bsaving/bloading and they are significantly different - I did not analyze them in detail yet. I could provide them if needed but I think that this can be reproduced quite easily.
The CLIPS program contains several user-defined function so that it will be of no use as-is but it does not contain anything special - plain rules without any specialities, COOL, modules, etc. I can provide it also if needed.
Do You need any other information?
Thanks Vranoch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I found the problem (at least the one that manifested to me). The problem was with saving/loading class-links (file objbin.c). In the function BsaveClassLinks are the links stored as (long) whereas in the function BloadObjects (line 1191) they were read as (DEFCLASS).
I do not know whether there isn't any other problem (I am not using COOL) but at least it works for me now. It should be perhaps defined better than (long) - perhaps something like (BSAVE_CLASS_LINK) but I leave it to someone more involved. Gary, will You please fix it correctly?
Thanks Vranoch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I found that on x64 architecture the bsave / bload features do not work-crash. When trying to execute the following batch:
(load "xy.clp")
(bsave "xy.bin")
(clear)
(bload "xy.bin")
the bload function crashes (corrupt memory). I found so far one bug:
objbin.c (581):
- formally was: GenWrite((void ) &space,sizeof(long),fp);
- changed to: GenWrite((void ) &space,sizeof(size_t),fp);
because in the corresponding read function there is (line 1049): GenWrite((void *) &space,sizeof(size_t),fp);
Fixing this I got to another deeper bugs. I am not quite familiar with such internals, could someone try to fix this, please?
Thanks Vranoch
Which version of CLIPS are you using? Where did you get it from? Which operating system are you using? Which compiler did you use? What is the contents of the xy.clp file?
Hello, sorry for missing the parameters. It is v6.30 checked out from this SVN couple of months ago (I watched the changes but I did not find any related). I use a MS Visual studio 2010 (I could even send the project). I do a test in which a text Clips program is generated (no COOL features), then a batch is created (as described) and run as (batch-star ). The test is run from a .NET environment but the named operations are called within a batch.
When the test is run against a CLIPS DLL compiled for a Win32 architecture (and under WOW64 - 32bit mode), everything is OK. When the identical test is run against a CLIPS DLL compiled for a x64 architecture and in a true 64 bit mode, the (bload ) fails for a memory corruption. I found one inconsistency between bload and bsave sequence of IO operations but currently I am stuck on bloading handles for a module. I even dumped the IO operations in both modes when bsaving/bloading and they are significantly different - I did not analyze them in detail yet. I could provide them if needed but I think that this can be reproduced quite easily.
The CLIPS program contains several user-defined function so that it will be of no use as-is but it does not contain anything special - plain rules without any specialities, COOL, modules, etc. I can provide it also if needed.
Do You need any other information?
Thanks Vranoch
Sorry, Win7Pro (x64), .NET 4
MS Visual Studio 2010 SP1
I think I found the problem (at least the one that manifested to me). The problem was with saving/loading class-links (file objbin.c). In the function BsaveClassLinks are the links stored as (long) whereas in the function BloadObjects (line 1191) they were read as (DEFCLASS).
formally: BloadandRefresh(theEnv,ObjectBinaryData(theEnv)->LinkCount,sizeof(DEFCLASS *),UpdateLink);
new: BloadandRefresh(theEnv,ObjectBinaryData(theEnv)->LinkCount,sizeof(long),UpdateLink);
I do not know whether there isn't any other problem (I am not using COOL) but at least it works for me now. It should be perhaps defined better than (long) - perhaps something like (BSAVE_CLASS_LINK) but I leave it to someone more involved. Gary, will You please fix it correctly?
Thanks Vranoch
I found an additional issue with the objbin.c code. Both your change and this new change have been checked into the svn repository.