yang686526

problem in opening file with 2.1.0
problem in opening file with 2.1.0
the attached file (3dcabinet222.dwg inside 3dcabinet222.zip) exhibits the following behavior when model space is imported using vectorization framework:
- windows (debug): throws assert (winaseert.png).
- windows (release): imports the view without any problem
- macintosh ppc (debug): imports the view without any problem
- macinthosh ppc (release): crashes (macppc_crashlog.txt contains relevant stacktrace at crash)
- macintosh intel (debug): crashes (mactel_crashlog.txt contains relevant stacktrace at crash)
- macintosh intel (release): imports the view without any problem
we are using static libs 2.1.0 built with vc8 on windows and xcode on macintosh.
is the file corrupt or does the problem lie somewhere else?
attached images
winassert is valid.
about mac's - we havn't mac pc here so it is difficult to comment such situation. try to explode solid object to regions and locate 'bad' region.
file is not corrupted. sometimes we got crashes in the release due to compiler code optimization, but you said that 'macintosh intel (release)' is ok.
last edited by sslezkin; 8th november 2006 at 06:45 amfff">.
can you reproduce this problem using our odvectorizeex sample on the mac? both debug and release builds (ppc) of odvectorizeex worked fine for me on this file.

forgot to mention, we use the universal builds (dd_macub) for both ppc and mactel.
and no, i was not able to check with odvectorizeex on mac. dd_nonlibsmac does not contain project files for xcode. the problem was reported when we were building with xcode 2.3. since then we've moved to xcode 2.4 and still the crash remains.
mactel release works ok for me.
crash is reproducible with debug builds on mactel and release builds on macppc 100% times.
curiously, dd_macub has only release version of the libs (against which we link both our debug and release targets) and yet the call stack shows the crash in dd on only one target on a specific platform (debug on mactel, release on macppc).
and about the assert on windows, why is it valid if the file is not corrupt?
regards,
varun
dwg file includes isolines\wires cache for solids. it is depend on viewport parameters like target and direction. usually, viewport parameters for cache is equal to mfcapp viewport parameters and toolkit used cache information. assert means that cache from file cannot be used, i.e. viewport parameters is not equal. it is valid situation too, but not standard.
hi. were you guys able to reproduce the crash on ppc using universal binaries version of dd?
to check on any of your samples, i'll need the relevant xcode project files. where can i get them?
regards,
varun
we don't have any stand-alone project files for xcode, but you can create one without much work, and just add in the source files from the examples/odvectorizeex directory along with the appropriate files from extensions/exservices.

hi,
here is my investigation so far:
- mac ppc release: if i pad 19 or more bytes at the begining of each memory allocation request made to odrxalloc()/odrxrealloc() then the file is imported correctly. if i pad 18 or less number of bytes, the crash occurs.
- mac intel debug: if i pad 583 or more bytes at the begining of each memory allocation request made to odrxalloc()/odrxrealloc() then the file is imported correctly. if i pad 582 or less number of bytes, the crash occurs.
also noted that on mac intel debug, using libdd_macub_alloc.a instead of our memory manager routines makes the problem go away.
however doing the same with macintosh ppc release does not fix the problem.
i suspect there is a out of bounds memory access for this particular file, somewhere close to the point that the crashlog indicates. can someone please look into this?
regards,
varun
sent a few more files with similar crash to .
regards,
varun
hi,
i am testing with dd 2.2.0 release and cannot reproduce this problem (either on mactel or ppc in both debug and release).
did you guys do something specific to fix this or has this issue been resolved with some other bug fix?
either way, thanks a lot!
regards,
varun