yang686526

dwgdirect crash when drawing dxf file
dwgdirect crash when drawing dxf file
we use the wingdi renderer to draw autocad files within our application. currently we are on version 1.13.xx, so we are behind in versions.
we are having a problem with some dxf files in that our application crashes with an access violation when we turn off a layer that had been on. the crash seems to be related to the gsmodel caching. we use gsmodel caching. if we turn it off, we don't have any more crashes. it seems to not crash if the layer we turn off does not have any elements (at least not any that we can tell).
so far, we have not been able to reproduce the problem in odamfcapp.
we have spent a lot of time debugging through the dwgdirect code, but we haven't found any obvious solution to our problem.
here is what we can tell (by comparing the path that odamfcapp takes - and doesn't crash - vs the path that our application takes - and crashes):
we turn the level on or off the same way that odamfcapp does it in odalayerpropmanagerdlg.cpp. we call player->setisoff, passing true or false, depending on whether we are turning the layer off or on. during our next draw/paint, we detect (based on our own internal data) that the layer status has changed so we use
code:
pdevice->gsmodel()->invalidate(odgsmodel::kinvalidateall)
to invalidate the model. then, we delegate the draw to dwgdirect via pdevice->update.
during the drawing/vectorization, we eventually get to
code:
odgibasevectorizer::draw(const odgidrawable* pdrawable) with this stack:
odgibasevectorizer::draw(const odgidrawable * 0x1968a9a8) line 765 + 18 bytes
odgsentitynode::update(odgsbasevectorizeview & {...}, odgscontainernode * 0x1a4b7968) line 864 + 49 bytes
odgscontainernode::update(odgsbasevectorizeview & {...}, odgscontainernode * 0x00000000) line 602 + 21 bytes
odgsbasevectorizeview::display(unsigned char 1) line 1599 + 19 bytes
odgsbasevectorizeview::update() line 1661 + 18 bytes
exgdivectorizeview::update() line 524
odgsbasevectorizedevice::update(odgsdcrect * 0x00000000) line 193 + 16 bytes
exgsgdivectorizedevice::update(odgsdcrect * 0x00000000) line 266
in odgibasevectorizer::draw, the code fails the compound drawable check and goes into the else:
code:
else
{
oduint32 ndrawableflags = setattributes(pdrawable);
if(needdraw(ndrawableflags))
dodraw(ndrawableflags, pdrawable);
}
next, we enter needdraw() and return false because of this statement:
code:
if(!getbit(m_flags, kdrawlayeroff) &&
!getbit(ndrawableflags, odgidrawable::kdrawableiscompoundobject | odgidrawable::kdrawableusesnesting) &&
traits.islayeroff()
the "getbit" tests are always the same, but traits.islayeroff() returns true (when the layer is off - i.e. it has just been turned off by our application). since needdraw returns false, dodraw is skipped. if we force the dodraw to execute by using "set next statement" in the debugger, we don't get a crash.
(the crash does not happen here, but it appears that if we execute dodraw we do not get the crash in the future, but if we don't execute dodraw, we do get a crash).
later we get to odgsentitynode::update. in that function, pgsmetafile == 0 (which seems right, based on the comments in the code, since we invalidated the gsmodel cache).
eventually, it gets to this section of code:
code:
// update extents
if( getbit(m_flags, karrayallocated) && metafilearray().size() > 1)
{
const vpmetafileholderptr* pmetafileptr = metafilearray().begin();
const vpmetafileholderptr* pmetafileendptr = metafilearray().end();
oda_assert(pmetafileptr!=pmetafileendptr);
while(pmetafileptr->isnull() && pmetafileptr!=pmetafileendptr)
{
++pmetafileptr;
}
if(pmetafileptr!=pmetafileendptr)
{
m_extents = (*pmetafileptr)->extents;
++pmetafileptr;
while(pmetafileptr!=pmetafileendptr)
{
if(pmetafileptr->get() && (*pmetafileptr)->extents.isvalidextents())
m_extents.addext((*pmetafileptr)->extents);
++pmetafileptr;
}
}
setbit(m_flags, khasextents, m_extents.isvalidextents());
}
metafilearray().size() is 0xfdfdfdfd (uninitialized data???)fff"> in the case where we crash. it is 1 when we don't crash (i.e. when we have not changed the state of any layers). both pmetafileptr and pmetafileendptr are 0. so, when the while loop starts, pmetafileptr->isnull() is being called with pmetafileptr == 0. this is where the crash happens.
in both odamfcapp and our application, the draw starts with exgsgdivectorizedevice::update and eventually gets to odgscontainernode::update.
odgscontainernode::update is called from this loop in odgsbasevectorizeview::display:
code:
void odgsbasevectorizeview::display(bool bupdate)
{
for(unsigned int i = 0; !regenabort() && i < m_drawables.size(); ++i)
{
drawableholder& holder = m_drawables[i];
odgsnode* pnode = getrootnode(holder);
if(pnode)
{
setbit(m_flags, kmodelcache, true);
if(bupdate)
pnode->update(*this, 0);
pnode->display(*this);
}
else // no model cache
{
setbit(m_flags, kmodelcache, false);
if(holder.m_pmetafile.get())
{
playmetafile(holder.m_pmetafile);
holder.m_pmetafile.release();
}
else
{
draw(drawableat(holder));
}
}
}
}
on both cases, since gsmodel caching is in effect, the code branches to the if(pnode)fff"> section, not the else // no model cachefff"> section. then control goes to odgscontainernode::needregen. in odamfcapp, when needregen calls childrenuptodate(), true is returned which causes the return statement at the end of the function (needregen) to execute, eventually causing needregen to return false. in our application, childrenuptodate() returns false, causing needregen to return true.
since needregen returns true in our application, the rest of odgscontainernode::update is executed. in odamfaapp, the rest of the function is skipped.
i know that this is a lot of information (hopefully at least some of it is useful!), but we really hope to get an answer. as much as we have tried, we cannot reproduce the problem in odamfcapp.
at this point, we can't tell if it is a bug in our code with maintaining the gsmodel cache or the layer status or if it is a bug in dwgdirect (wingdi or "real" dwgdirect code), or it is a problem in our dxf files. we were first notified of the problem based on dxf files that a customer created (don't know how they created them at the moment), but we have since found some dxf files that we already had and they had the same problem. so far, we have not seen the problem with dwg files. maybe it is a problem in wingdi/dwgdirect that exists in our version but has been fixed in a more recent version.
any help would be greatly appreciated.
i forgot to attach the file.
here is a dxf file that causes us to crash (again, it doesn't crash odamfcapp).
attached files (23.4 kb, 4 views)