Undo Crash - how to find the problem?

[Kyudos]

I have a function that creates many custom objects, numerous times (if the user wants). I've used undo "begin" and "end" markers so that the user can undo each group.

However, if I (say) use my tool to create three groups then undo them all, after the third undo AutoCAD (2016) crashes with:

Exception thrown at 0x000007FEFD90A06D (KernelBase.dll) in acad.exe: 0xE0434352 (parameters: 0xFFFFFFFF80131500, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x000007FEF8E30000).
Unhandled exception at 0x000007FEFD90A06D (KernelBase.dll) in acad.exe: 0xE0434352 (parameters: 0xFFFFFFFF80131500, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x000007FEF8E30000).

and call stack:

 KernelBase.dll!000007fefd90a06d()	Unknown
 clr.dll!000007fef8f0fcf1()	Unknown
 clr.dll!000007fef8f0faf0()	Unknown
 000007fe99ec0291()	Unknown
 Acmgd.ni.dll!000007fec78db71f()	Unknown
 Acmgd.ni.dll!000007fec78da8fe()	Unknown
 Acmgd.ni.dll!000007fec789157f()	Unknown
 Acmgd.ni.dll!000007fec7891987()	Unknown
 Acmgd.ni.dll!000007fec7935b73()	Unknown
 AcLayer.ni.dll!000007fec20beae5()	Unknown
 AcLayer.ni.dll!000007fec20bd22a()	Unknown
 Acmgd.ni.dll!000007fec792209f()	Unknown
 Acmgd.ni.dll!000007fec78d9d3d()	Unknown
 clr.dll!000007fef8ea7c9e()	Unknown
 acbol.dll!000007fedacae14e()	Unknown
 acbol.dll!000007fedacbd1a4()	Unknown
 accore.dll!000007fed2484eaf()	Unknown
 accore.dll!000007fed291665f()	Unknown
 acad.exe!000000014006bd2f()	Unknown
 acad.exe!000000013fd98985()	Unknown
 accore.dll!000007fed225d8ce()	Unknown
 accore.dll!000007fed225d6e3()	Unknown
 accore.dll!000007fed22324bb()	Unknown
 accore.dll!000007fed2231c60()	Unknown
 accore.dll!000007fed2231b18()	Unknown
 accore.dll!000007fed21f3018()	Unknown
 accore.dll!000007fed21b5e77()	Unknown
 accore.dll!000007fed219b925()	Unknown
 accore.dll!000007fed2a23218()	Unknown
 accore.dll!000007fed225d738()	Unknown
 acad.exe!000000013fda4169()	Unknown
mfc110u.dll!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47	C++

Obviously, that isn't my code - any idea what the cause might be? Or how I might discover the cause?

[Kyudos]

At other times I get a crash at the same address when try an acedGetPoint, if that sheds any light...

[Kyudos]

This seems to come about if I create more than 256 new objects in one go. Is there some sort of transaction / database size limit I don't know about??

EDIT:

Actually - this smells like the open object for read limit....investigating...

[tbrammer]

Did you check your dwgInFields() and dwgOutFields() methods?

Do you always call assertWriteEnabled() in your setXXX() methods?

[Kyudos · Accepted solution]

I use transactions (almost) exclusively it turns out this was down to an iteration over the linetype table.

Inside the transaction I was using:

es = acdbOpenObject(pObj, id, AcDb::kForRead);

I fixed the problem by changing that to:

es = acdbTransactionManager->getObject(pObj, id, AcDb::kForRead);

So I'm happy it's now working ...but...

• It shouldn't really matter how I open an object inside a transaction
• If you're going to leave it 'broken' (as above), hitting the 'read' limit should have a more graceful exit strategy that crashing in an unrelated bit of code.

[artc2]

Were you calling close() for each of the acdbOpenObject() calls? If not, then the read count will increase and when it hits the limit the open code returns eAtMaxReaders. What happens then, of course, depends on the calling code.

[Alexander.Rivilis]

@Kyudos

My recommendation is using smart pointers (such as AcDbObjectPointer):

AcDbObjectPointer<AcDbObject> pObj(id, AcDb::kForRead);

if (pObj.openStatus() == Acad::eOk)
{
  // Your code...
}

pObj destructor call pObj->close() in any case.

[Kyudos]

I wasn't calling close, that was the problem. I didn't think it was necessary, since I was inside a transaction. Really, if the intention of the transaction system was to stop you having to remember to close your objects, then once a transaction is open, objects should be added to it however they are opened...

[artc2]

Effectively, transactions and open/close are two separate mechanisms that work side by side. So, if you use both, then you must fully use both.

And, because of the complexity of the two mechanisms, there have been issues over the years when using both at the same time on an object. The issues were fixed as they were discovered, but to avoid any undiscovered issues, I recommend that you use one or the other, but not both at the same time on an object.