yang686526

crash in dd_root.dll on hyperthreaded cpu
crash in dd_root.dll on hyperthreaded cpu
hi,
i am having some random crashes in dbobject.cpp line:399. my call stack looks like this at the time of crash:
dd_root.dll!00d5df18()
dd_root.dll!00d5df98()
dd_db.dll!0157c325()
dd_db.dll!0157d2a6()
dd_gi.dll!00f0e672()
dd_gi.dll!00f0e78d()
dd_gs.dll!01000712()
dd_gi.dll!00f0ea45()
dd_gi.dll!00f0de43()
dd_gi.dll!00f0dc50()
here is the setup that creates this crash: i am having 2 odgslayouthelper devices: one that draws the database and second that draws overlay entities. i use critical_sections to change properties of overlay entity (eg. oddbpoint). the crash occurs randomly as shown above when overlay entity gets changed(eg. changing position of oddbpoint).
i can always reproduce this crash on pentium-4 hyperthreaded cpus but can not produce it on non-hyperthreaded cpus.
is there any clue what might be going wrong in here?
thank you.
which version are you using?
dwgdirect is supposed to be thread safe starting with 1.14.02 if different databases are accessed from different threads.
accesing the same database from different threads is not safe.
if some thread modifies database in critical section be sure to close all modified objects (no smart pointers should exist pointing to modified objects after leaving critical section).
also if rendering thread is running at the moment objects are modified by another thread the rendering thread should be restarted.
sergey slezkin
sergey,
can you elaborate?
quote:
if some thread modifies database in critical section be sure to close all modified objects (no smart pointers should exist pointing to modified objects after leaving critical section).
also if rendering thread is running at the moment objects are modified by another thread the rendering thread should be restarted.
we are using a critical section to protect the database on an add. unfortunately, we have this trouble on enitities that aren't added to the database. they are merely overlay objects that provide visual feedback for our tools. all are derived of odgidrawable (either as oddbobjects or odgidrawables themselves). we dont exhibit any trouble on single cpu machines and so we need more info to track this down.
thanks
tyler
sergey,
can you give me a snap shot of the code around dbobject.cpp line:399
we just can't tell if this is a threading issue or something else.
also... can you think of any other threading gotchas that have arisen? we are really struggling with this particular issue.
thanks
tyler