yang686526

incompatibility with a 3rd party library
incompatibility with a 3rd party library
hello,
we are developing an application that uses a 3rd party graphic library for 3d rendering. for the new version of the application, our client wants to be able to import and export autocad drawings (dwg/dxf). a mfc prototype has been made that uses the gdi module (wingdi_gs) to vectorize the cad files. however, since that prototype has been integrated in the main application, we are getting asserts and/or crashes while reading dwg files.
after investigating, we found out the problem occurs when the graphic library engine is initiliazed before reading the file. so it would seem there are conflicts between the two libraries. we modified the singledoc sample to add only the graphic library initialization and the same problems happen (see attachment).
what we have observed so far:
reading/vectorizing a dwg before initializing the graphic library engine works fine (not an option).
on all files we get 3 harmless asserts (they can be safely ignored but odly ignore/retry seem to be swapped):
ep.isequalto(pe, odgetol(radius() * 1e-8)) in gecircarc2d.cpp (zoomextents or device update)
ep.isequalto(pe, odgetol(radius() * 1e-8)) in gecircarc3d.cpp (zoomextents or device update)
mret == mdbg in dbblockreference.cpp (zoomextents or device update)
on some files we get other asserts ('invalid operator<', 'invalid sequence', etc.) that will crash the application or lead to an exception being raised (readfile).
the key points causing issues (zoomextents, readfile or device update) when put in separated threads, do not give these asserts. unfortunately, the device update is not thread safe (i.e. will crash randomly). if we do everything but the device update in separated threads, the update method gives an error 253 : not initialized yet.
has anyone come accross similar problems?
we'd appreciate if anyone could give us any information in order to fix/avoid that problem.
thanks in advance.
ps: we cannot start a support request due to issues with our ftp account.
pps: the attached executables are compiled with debug dlls.
attached files
i have no idea how .exe files without sources may help.
note that odininitialize() must be called before any module (including wingdi.gs) is loaded.
what do you mean by "initializing the graphic library engine"? it's about 3-d party library? is it possible that it uses dwgdirect parts?
also note that accessing the same oddbdatabase object from different threads is not safe.
sergey slezkin
quote:
originally posted by sslezkin
i have no idea how .exe files without sources may help.
as i said the problems occur in the dwgdirect library (e.g. gecircarc2d.cpp, gecircarc3d.cpp, dbblockreference.cpp, etc.) so you have all the source code you need. you can debug your code by attaching the debugger to my executable (compiled with visual studio c++ 2005 sp1) and trace what happens in the oddbhostappservices2::readfile function.
if it makes any difference here is the only code that has been added to the singledoc sample
(rwengineinit, rwengineopen & rwenginestart are part of the graphic library and we don't have access to their source code either):
code:
int initworld(cwnd *pwnd_in)
{
rwengineopenparams openparams;
rwbool res = rwengineinit(null, 0, 4 << 20);
if (!(openparams.displayid = pwnd_in->getsafehwnd()))
return -1;
if (!rwengineopen(&openparams))
return 1;
if (!rwenginestart())
return 1;
return 0;
}
...
bool csingledocdoc:nopendocument(lpctstr lpszpathname)
{
if (!cdocument:nopendocument(lpszpathname))
return false;
/**********************************************************************/
/* load the specified dwg file into the database, allow code page */
/* conversion disallow partial load. */
/**********************************************************************/
try
{
if (!m_pdb.isnull()) // clear gs model associated with the previous database
{
position pos = getfirstviewposition();
while (pos)
{
csingledocview* view = (csingledocview*)getnextview(pos);
view->m_pdevice = 0;
view->m_pprinterdevice = 0;
if (initworld(view) != -1)
binitworld = true;
}
}
m_pdb = theapp.readfile(lpszpathname, true, false);
}
catch(oderror& /*e*/)
{
}
catch(userbreak)
{
return false;
}
return true;
}quote:
originally posted by sslezkin
note that odininitialize() must be called before any module (including wingdi.gs) is loaded.
yes, i'm aware of that.
quote:
originally posted by sslezkin
what do you mean by "initializing the graphic library engine"? it's about 3-d party library? is it possible that it uses dwgdirect parts?
yes, the graphic library is the 3rd party one and it has nothing to do with directdwg. it is 'renderware graphics 3.5'.
quote:
originally posted by ng@ice-dev.com
we are developing an application that uses a 3rd party graphic library for 3d rendering.
quote:
originally posted by sslezkin
also note that accessing the same oddbdatabase object from different threads is not safe.
thanks, i had a feeling it wouldn't be. however, if we were to associate a mutex with the database that'd be locked for each access to the database object, do you think it would be possible to use the database in a multi-thread context?
quote:
on all files we get 3 harmless asserts (they can be safely ignored but odly ignore/retry seem to be swapped):
ep.isequalto(pe, odgetol(radius() * 1e-8)) in gecircarc2d.cpp (zoomextents or device update)
ep.isequalto(pe, odgetol(radius() * 1e-8)) in gecircarc3d.cpp (zoomextents or device update)
mret == mdbg in dbblockreference.cpp (zoomextents or device update)
these assertions indicate incorrect calculation or loss of precision. if they do not occur without the 3-rd party library initialization than it seems that the 3-rd party library sets reduced fp precision (see _control87() or _controlfp() ).
theoretically if you associate a mutex with database and implement your own thread synchronization providing that treads are not interrupted inside dwgdirect functions it may work.
sergey slezkin