toxic plugin

I’m using OS X 10.8.4 and Xojo 2013 Release 2.

My current fp Plugin v. 6.3, built either under Xcode 3.2.5 or Xcode 4.6.3 and in zip format with .xojo_plugin suffix or .rbx format, works just fine with Xojo. and Real Studio 2012 r 2.1.

Since all my mathematical plugins use no Cocoa calls or graphics, I’ve always used the 2008 versions of Glue Code and Includes. I decided to update with the latest versions of Glue Code and Includes. With the new fpPlugin.rbx, opening Real Studio 2012 r 2.1 itself gave a window stating there was a problem with opening. With the new fpPlugin.xojo_plugin, opening Xojo itself resulted in a crash, in which the crash report said that Thread 0 of the application Xojo had crashed.

When I used the new Glue Code and Includes with my simpler Complex Plugin no problems arose. Xojo did not crash.

Now there are no differences in principle in the designs of my fp Plugin and my Complex Plugin. So I have no idea as to why that toxic fp Plugin crashes Xojo.

Any ideas?

Bob

So how can we help?
Crashlog? Code?

delaneyrm.com/XojoCrashReport.rtf.zip

And here’s the source code:
delaneyrm.com/fpPluginToxic.zip

without checking the code I vote on a bug in the structures. Like having a methodcount being incorrect.

Here’s my method count:

for (i = 0; i < sizeof(otherBigIntegerMethods) / sizeof(REALmethodDefinition); ++i)
REALRegisterMethod(&otherBigIntegerMethods[i]);
for (i = 0; i < sizeof(otherBigFloatMethods) / sizeof(REALmethodDefinition); ++i)
REALRegisterMethod(&otherBigFloatMethods[i]);
for (i = 0; i < sizeof(otherBigComplexMethods) / sizeof(REALmethodDefinition); ++i)
REALRegisterMethod(&otherBigComplexMethods[i]);
for (i = 0; i < sizeof(otherComplexVectorMethods) / sizeof(REALmethodDefinition); ++i)
REALRegisterMethod(&otherComplexVectorMethods[i]);
for (i = 0; i < sizeof(otherBigFractionMethods) / sizeof(REALmethodDefinition); ++i)
REALRegisterMethod(&otherBigFractionMethods[i]);

code $0 = {
(long) version = 11
(const char *) name = 0x14d60b75 “BigInteger”
(const char ) superName = 0x00000000
(long) dataSize = 12
(long) forSystemUse = 0
(REALproc) constructor = 0x14d1587a (fp Plugin.dylibBigIntegerConstructor(REALobjectStruct*) at fp Plugin.cpp:36) (REALproc) destructor = 0x14d158ac (fp Plugin.dylibBigIntegerDestructor(REALobjectStruct
) at fp Plugin.cpp:151)
(REALproperty *) properties = 0x00000000
(long) propertyCount = 0
(REALmethodDefinition *) methods = 0x14de712c
(long) methodCount = 115
(REALevent *) events = 0x00000000
(long) eventCount = 0
(REALeventInstance *) eventInstances = 0x00000000
(long) eventInstanceCount = 0
(const char *) interfaces = 0x00000000
(REALattribute *) attributes = 0x00000000
(long) attributeCount = 4
(REALconstant *) constants = 0x00000000
(long) constantCount = 0
(long) mFlags = 4
(REALproperty *) sharedProperties = 0x00000000
(long) sharedPropertyCount = 0
(REALmethodDefinition *) sharedMethods = 0x00000000
(long) sharedMethodCount = 0
}[/code]

Here’s your class declaration, viewed in a debugger for clarity.

The problem is that you’re passing in REALconsoleSafe where attributeCount is, so the IDE goes off and looks for 4 attributes at address 0. Previously this was an ignored bit of the structure and you got away with passing REALconsoleSafe at a bogus place, but the field got reused when attributes were added.

Joe,

Thanks very much for finding that!

Bob

Here’s my current REALclassDefinition. Since it’s so easy to get this wrong, I’d appreciate your comments. In particular if I have no interface string, should that field be nil?
REALclassDefinition BigIntegerClass = {
kCurrentREALControlVersion,
“BigInteger”, // name of class
nil, // no superclasses
sizeof(BigIntegerData), // size of our data
0, // for system use
nil, // initializer
nil, // finializer
nil, // properties
0, // property count
BigIntegerMethods, // methods
sizeof(BigIntegerMethods) / sizeof(REALmethodDefinition), // method count
nil, // Events
0, // Event count
nil, // eventInstances
0, // eventInstanceCount
nil // interface strings
nil // obsolete1
nil // obsolete2
nil, // constants
0, // constantCount
REALconsoleSafe, // flags
nil, // shared properties
0, // sharedPropertyCount
nil, // shared methods
0, // sharedMethodCount
};

[quote=27812:@Robert Delaney]Here’s my current REALclassDefinition. Since it’s so easy to get this wrong, I’d appreciate your comments. In particular if I have no interface string, should that field be nil?
REALclassDefinition BigIntegerClass = {
kCurrentREALControlVersion,
“BigInteger”, // name of class
nil, // no superclasses
sizeof(BigIntegerData), // size of our data
0, // for system use
nil, // initializer
nil, // finializer
nil, // properties
0, // property count
BigIntegerMethods, // methods
sizeof(BigIntegerMethods) / sizeof(REALmethodDefinition), // method count
nil, // Events
0, // Event count
nil, // eventInstances
0, // eventInstanceCount
nil // interface strings
nil // obsolete1
nil // obsolete2
nil, // constants
0, // constantCount
REALconsoleSafe, // flags
nil, // shared properties
0, // sharedPropertyCount
nil, // shared methods
0, // sharedMethodCount
};[/quote]

Yeah, NULL is treated the same as an empty string for interfaces.

Thanks Joe. Sorry about the missing commas in my previous post.