yang686526

crash in release mode
crash in release mode
hi,
i have recently updated our dwgdirect to version 1.13.1 and i am noticing that in release mode it would always crash at the "free" function. it doesn't happen in debug mode. it seems as though dwgdirect is over riding the "free" function. has anyone had this before??
here is the call stack
> ntdll.dll!7c911e58()
ntdll.dll!7c910d5c()
msvcr71.dll!free(void * pblock=0x01e44ba8) line 103 c
mfc71.dll!cstringlist::`vector deleting destructor'() + 0x43 c++
wyg.exe!006eaf9a()
01e1e434()
thanks

in which situation does it crash? are you able to reproduce the problem in our samples?
sincerely yours,
george udov
i am getting "unhandled exception at 0x7c92ae22 in wyg.exe: 0xc0000005: access violation reading location 0x0000000."
i am not able to reproduce in the sample code. i am not even running any of the dwg codes. i suspect that it maybe something not linked properly or one of the header maybe overriding the "free" function.
thanks
i have investigated this a little further. i have removed all includes and references to opendwg. the only thing i did was in visual studio under configuration properties/linker/input/additional dependencies, i added all the lib files that link to dll's, i get these errors. if i remove those lib files from dependencies, this problem doesn't happen.
one other thing was when i get this crash, and i try to replace the dll's, it seems dd_alloc.dll was in use. that means the free is infact using dd_alloc.dll's free rather than vc++'s free. even though there are no reference to opendwg.
thanks
i have notice that the odamfcappdll example in vs2003 release mode is also getting the same problem. it is generating an "unhandled exception at ... in odamfcappdll.exe: user breakpoint." the call stack looks very much like mine
ntdll.dll!7c901230()
ntdll.dll!7c96cd80()
ntdll.dll!7c96df66()
ntdll.dll!7c94a5d0()
ntdll.dll!7c9268ad()
> msvcr71.dll!free(void * pblock=0x01067948) line 103 c
mfc71.dll!cmultidoctemplate::`scalar deleting destructor'() + 0x15 c++
mfc71.dll!cdocmanager::~cdocmanager() line 1025 + 0x9 c++
mfc71.dll!cdocmanager::`vector deleting destructor'() + 0x18 c++
mfc71.dll!cwinapp::~cwinapp() line 591 c++
odamfcappdll.exe!00427f2f()
msvcr71.dll!exit(int code=0) line 303 + 0xd c
odamfcappdll.exe!0043a2ac()
kernel32.dll!7c816d4f()
please look at this. the code is very similar to what i have downloaded for version 1.13.2. if you want, i can compress the files and send it to you, but i have made no changes.
thanks
similar problem was fixed in 13.02 (currently available from web site).
sergey slezkin
i am already using 1.13.2. i have downloaded again just in case i have got the wrong files. the results are the same as before. can you please look at this problem.
thanks
do you mean that odamfcapp sample is crashing on your machine in release mode?
vladimir
quote:
originally posted by wvk
do you mean that odamfcapp sample is crashing on your machine in release mode?
yes, that is what i am saying.
does it crash on any file or just on some files?
are you sure you have not mixed 1.13.02 with 1.13.00?
how can we reproduce the problem?
vladimir
hi
i have attached odamfcappdll.exe, dd_alloc.dll and project. i notice that if i am in view/tile mode in windows explorer. all the other dll's say 1.13.2.0. however the dd_alloc.dll doesn't say anything and that dll causes the problem. this is the win32/vc2003 version. not sure if you have attached the older dd_alloc.dll with 1.13.2.0
to reproduce the problem, just open the application using odamfcappdll.vcproj. press f5 and then close odamfcappdll.zip
thanks
attached files (182.4 kb, 3 views)
(358.1 kb, 3 views)

i still cannot reproduce the crash:
i take dd_vc2003.zip from 1.13.02 distribution, unzip it, put there odamfcappdll and dd_alloc from your archive, run it and get no crash on exit.
i discovered one thing though:
dd_alloc in vc2003 distribution is indeed not a default one. that is - it was built from exalloc sample and uses experimental quickheap code. this may be the cause of your problem.
when developing our custom heap we encountered similar symptoms: it seems that while optimizing code compiler is not always correctly substitutes overloaded operator new/delete - it sometimes inline destructor call to "free", and calls overloaded new in constructor. this mix results in a crash.
this problem was encountered only in dwf libraries though. rest of the toolkit worked correctly.
anyway, you should try to replace dd_alloc with default one.
to build default dd_alloc replace exalloc.cpp contents with the following:
code:
#include <stdlib.h>
#include "odalloc.h"
extern "c"
{
allocdll_export void* odrxalloc(size_t s)
{
return ::malloc( s );
}
allocdll_export void* odrxrealloc(void* p, size_t new_size, size_t /*old_size*/)
{
return ::realloc( p, new_size );
}
allocdll_export void odrxfree(void* p)
{
::free( p );
}
} // extern "c"
and build exalloc dll.
vladimir