experiences with 64 bit OS

[tge]

Hi all,

recently I tried to run my Clips code on 64bit Windows. I have built
all the C sources with MSVC++ 9.0 without problems but when running
it, Clips crashes somewhere deep inside.
Code base is 6.30 with all the latest changes from the source code
repo
http://clipsrules.svn.sourceforge.net/viewvc/clipsrules/core/

The same constellation has been working for years with 32bit (Linux +
Windows) without any problems whatsoever, so I'm afraid this is a
64bit issue. Interestingly, Linux64 runs nicely, too.

I can load a bunch of CLP files, create instances, but within a
Reset() I get an access error,
100% reproducible. If I do a (watch all) I can see that all the
instances are initialized nicely, but afterwards trying to determine
activations, the crash occurs.

Now - what are the experiences with 64bit Windows in the community?
Any advice?

Many thx + best regards,
tge

[CLIPS Support]

Can you send the files needed to reproduce the issue?

On May 27, 9:38 am, tge <t...@blue-elephant-systems.com> wrote:
> Hi all,
>
> recently I tried to run my Clips code on 64bit Windows. I have built
> all the C sources with MSVC++ 9.0 without problems but when running
> it, Clips crashes somewhere deep inside.
> Code base is 6.30 with all the latest changes from the source code

> repohttp://clipsrules.svn.sourceforge.net/viewvc/clipsrules/core/

[tge]

Mmm, it's not that easy ... the whole thing is something like a
standalone agent consisting of a main prog
which loads various libs, config, data, ... then it instantiates an
embedded Clips engine, reads Clips code etc.

The pure Clips files will not help because we also define a set of
UserFunctions which are required.

What I can do is to build a debuggable Installer with everything
inside - this reflects what we are using and where
we experience the problem. This also includes all the Clips files,
plus I could add an archive with the Clips sources as being used (I
don't expect you to look through them :-) but rather to make sure they
match the executable code).

Alternatively (even easier) we could give you access to our dev/test
system (via OpenVPN + Remote Desktop)
What do you think?
Many thx in advance!!
tge

PS: Btw, I also let the whole thing run through valgrind (on Linux)
and purify (we have on Windows32 only :-|) - nothing.
PS2: I also spent quite some times searching through discussions
related to Windows topics such as mixing debug and non-debug code
which originally caused major troubles, but the exact same problem
appears in debug as well as in pure non-debug code. Therefore I guess
we can exclude this too.

[tge]

I tried to debug this and found a few more details:
- it's not happening after all objects have been created by a reset()
but in the middle of a (definstances ...)
- I can see in the stack and variables which particular instance and
slot is being processed, however I cannot see anything wrong/special
with that
(stack see below) - at this point also the stack and all variables
I looked at look quite ok
- at the bottom of the stack however, there is a "join" being
evaluated which is rubbish

Here is the stack
===============
libClipsAPI!UpdateBetaPMLinks(void * theEnv = 0x00000000`00b26f80,
struct partialMatch * thePM = 0x00000000`03701410, struct partialMatch
* lhsBinds = 0x00000000`037009b0, struct partialMatch * rhsBinds =
0x00000000`036f2490, struct joinNode * join = 0x00000000`01614400,
unsigned long hashValue = 0, int side = 0)+0x97 [y:\external\clips
\6.30\src\reteutil.c @ 203]
libClipsAPI!PPDrive(void * theEnv = 0x00000000`00b26f80, struct
partialMatch * lhsBinds = 0x00000000`037009b0, struct partialMatch *
rhsBinds = 0x00000000`036f2490, struct joinNode * join =
0x00000000`01614160)+0x140 [y:\external\clips\6.30\src\drive.c @ 872]
libClipsAPI!NetworkAssertLeft(void * theEnv = 0x00000000`00b26f80,
struct partialMatch * lhsBinds = 0x00000000`037009b0, struct joinNode
* join = 0x00000000`01614160)+0x275 [y:\external\clips\6.30\src
\drive.c @ 439]
libClipsAPI!EmptyDrive(void * theEnv = 0x00000000`00b26f80, struct
joinNode * join = 0x00000000`01613f20, struct partialMatch * rhsBinds
= 0x00000000`036fd440)+0x45f [y:\external\clips\6.30\src\drive.c @
1061]
libClipsAPI!NetworkAssert(void * theEnv = 0x00000000`00b26f80, struct
partialMatch * binds = 0x00000000`036fd440, struct joinNode * join =
0x00000000`01613f20)+0x5e [y:\external\clips\6.30\src\drive.c @ 95]
libClipsAPI!CreateObjectAlphaMatch(void * theEnv =
0x00000000`00b26f80, struct objectAlphaNode * alphaPtr =
0x00000000`016024a0)+0x20b [y:\external\clips\6.30\src\objrtmch.c @
1142]
libClipsAPI!ProcessPatternNode(void * theEnv = 0x00000000`00b26f80,
int offset = 0, struct objectPatternNode * patternNode =
0x00000000`01553c30, struct multifieldMarker * endMark =
0x00000000`00000000)+0x2cd [y:\external\clips\6.30\src\objrtmch.c @
959]
libClipsAPI!ObjectPatternMatch(void * theEnv = 0x00000000`00b26f80,
int offset = 0, struct objectPatternNode * patternTop =
0x00000000`01553c30, struct multifieldMarker * endMark =
0x00000000`00000000)+0x223 [y:\external\clips\6.30\src\objrtmch.c @
835]
libClipsAPI!ObjectAssertAction(void * theEnv = 0x00000000`00b26f80,
struct instance * ins = 0x00000000`036f9480)+0x86 [y:\external\clips
\6.30\src\objrtmch.c @ 1282]
libClipsAPI!ProcessObjectMatchQueue(void * theEnv =
0x00000000`00b26f80)+0xae [y:\external\clips\6.30\src\objrtmch.c @
610]
libClipsAPI!ObjectNetworkAction(void * theEnv = 0x00000000`00b26f80,
int type = 0, struct instance * ins = 0x00000000`00000000, int
slotNameID = -1)+0x18f [y:\external\clips\6.30\src\objrtmch.c @ 321]
libClipsAPI!SetDelayObjectPatternMatching(void * theEnv =
0x00000000`00b26f80, int value = 0)+0x79 [y:\external\clips\6.30\src
\objrtmch.c @ 156]
libClipsAPI!InactiveMakeInstance(void * theEnv = 0x00000000`00b26f80,
struct dataObject * result = 0x00000000`0012e7d8)+0x3e [y:\external
\clips\6.30\src\insmngr.c @ 618]
libClipsAPI!EvaluateExpression(void * theEnv = 0x00000000`00b26f80,
struct expr * problem = 0x00000000`016b3320, struct dataObject *
returnValue = 0x00000000`0012e7d8)+0x6f3 [y:\external\clips\6.30\src
\evaluatn.c @ 351]
libClipsAPI!ResetDefinstancesAction(void * theEnv =
0x00000000`00b26f80, struct constructHeader * vDefinstances =
0x00000000`015b8e90, void * userBuffer = 0x00000000`00000000)+0x89 [y:
\external\clips\6.30\src\defins.c @ 935]
libClipsAPI!DoForAllConstructs(void * theEnv = 0x00000000`00b26f80,
<function> * actionFunction = 0x00000000`00f70c40, int moduleItemIndex
= 7, int interruptable = 1, void * userBuffer =
0x00000000`00000000)+0xef [y:\external\clips\6.30\src\cstrccom.c @
1258]
libClipsAPI!ResetDefinstances(void * theEnv =
0x00000000`00b26f80)+0x3d [y:\external\clips\6.30\src\defins.c @ 898]
libClipsAPI!EnvReset(void * theEnv = 0x00000000`00b26f80)+0x175 [y:
\external\clips\6.30\src\constrct.c @ 399]
===============

All data I'm looking at look ok to me (addresses look OK, or are NULL,
content data appears to be reasonable) until
the very bottom of the stack:

reteutil.c:203:
=========
if (side == LHS)
{
thePM->nextInMemory = theMemory->beta[betaLocation];
...
And theMemory->beta is obviously rubbish:

theMemory 0x00000000`01604590 struct betaMemory *
size 0xfeeefeee
count 0xfeeefeee
beta 0xfeeefeee`feeefeee
last 0xfeeefeee`feeefeee

A bit up, "theMemory" is assigned from:
theMemory = join->leftMemory;
also rubbish - actually the pointer "theMemory" itself looks ok, but
not the memory it is pointing to.

Going up the stack, "join" is passed downwards ... I went up until
CreateObjectAlphaMatch() checking the data structures associated with
the joins and all looks good (reasonable data etc), there are many
objects referencing each other, but in the end I always can route
myself until the bad memory.

Is my understanding right, that the joining data structures are
actually the result of "compiling" the loaded rules? That would mean
that either the offending memory gets overwritten during runtime or is
not initialized properly?

Hmmm ...

[tge]