![]() |
【转帖】problems shutting down in release builds
problems shutting down in release builds
problems shutting down in release builds hi there, i'm currently having occasional (reproduceable) crashes when i shut my application down. strangely, it only happens in the release build - debug is fine. i've attached an extremely cut down piece of code that demonstrates the problem and my compile/link lines. commenting out the call to oddbspline::setnurbsdata() stops the crash . . . i'm using dwgdirect v1.13.01 in my application, msvc6 dll build. i've just downloaded v1.13.02 and the problem appears to still be present. any pointers you can give me as to what i'm doing wrong would be appreciated - thanks jon attached files dear jon, i failed to reproduce your issue, but there is one question. please try to replace calls of "append" method of odarrays by calls of "push_back" method. will crash appear in this case? sincerely yours, george udov hi george, i've replaced the append calls with calls to push_back, but i still get the crash. i've also tried changing the code around so the services go out of scope before oduninitialize() is called but this also had no affect. i've attached my dll and lib that i link with - everything else is a dwgdirect library. hope this helps . . . jon attached files (76.9 kb, 6 views) hello again, do you have any news on this please? several of my application's unit and macro tests are failing in release builds because of this . . . thanks jon jon, i still can't reproduce any problems. are you sure that everything is ok on your side? what alignment size do you use? if still issues - could you please make minimal project in vc6 reproducing the problem, zip it, and post to forum? (project that i can compile and link after appending dd libraries). sincerely yours, george udov hi george, i've attached a msdev project which should hopefully demonstrate the problem - you should just need to copy the dwgdirect dlls and libs into the debug/release directories and change the include paths. this project fires the purecall assertion for me in a development build and throws an exception in release. i've had problems with the purecall assertions in the past when some of my dwgdirect objects were still in scope when i called oduninitialise() but i don't see how that can be the problem here? anyway - thanks for looking at this jon attached files (147.1 kb, 11 views) jon, i changed a bit your main() function, and now there are no any pure virtual calls and exceptions: code: int main(int argc, char *argv[]) { { odrxobjectimpl<myservices> services; odinitialize(&services); { int degree = 4; int num_cpts = 9; int num_knots = 12; // a dwg entity to hold this nurb oddbsplineptr spline = oddbspline::createobject(); // dwg entities to hold control points,knots and weights odgepoint3darray cpts; odgedoublearray kts; odgedoublearray wts; // save the knots for (int i = 0;i < num_knots;++i) { //kts.append(i); kts.push_back(i); } // save the control points for (i = 0; i < num_cpts; ++i) { //cpts.append(odgepoint3d(i,i,i)); cpts.push_back(odgepoint3d(i,i,i)); } // save the weights for (i = 0; i < num_cpts; ++i) { //wts.append(1.0); wts.push_back(1.0); } // some tolerances double tol = 1e-3; double rat_tol = 1e-10; // set all this info into the dwg entity spline->setnurbsdata(degree,false,false,false,cpts,kts,wts,tol,rat_tol); } oduninitialize(); } return 0; } services are required for uninitialisation, so oduninitialize(); must be called before services gets out of scope. still can't reproduce any release-only crashes. sincerely yours, george udov last edited by george udov; 26th october 2005 at 02:55 amfff">. hi george, thanks for looking at this, but commenting out the call to setnurbsdata() is not really an option - its an integral part of the test that the code fragment is extracted from. it looks like all dwgdirect smart ptrs are out of scope when oduninitialise() is called, unless something is happening in the background in the setnurbsdata() method? is there something else that i should be doing? thanks jon it seems i misprinted. please read my prev. msg once more (i corrected it). sincerely yours, george udov sorry - it looks like i sent you the wrong version of the code as well - i'd experimented with changing the scope of the services and forgot to change it back. if i use the code as it is above then a development build works ok, but i still get an exception thrown in a release build. the dialog i get is "unhandled exception in dwgtest.exe (dd_alloc.dll): 0xc0000005: access violation". msdev seems to show that the program is in dd_alloc at address 0x004113eb (the debugger can get this wrong in release builds though) i can't think what could be causing this to go wrong for me while it is fine for you. could it be my alloc implementation? my file looks like this : #include "dwgdirect/odalloc.h" #include <stdlib.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 the object is linked into my libdwgservices.dll - all of the other code in that dll is straight from the exservices example directory. one other thing, i added this code : _asm { int 3 } on the line before the oduninitialize() call to force the program to raise a break point. the break point was not reached in the release build, so it looks like the error is happening for me somewhere in the destructors called at the end of the inner scope. quote: originally posted by jon k if i use the code as it is above then a development build works ok, but i still get an exception thrown in a release build. the dialog i get is "unhandled exception in dwgtest.exe (dd_alloc.dll): 0xc0000005: access violation". msdev seems to show that the program is in dd_alloc at address 0x004113eb (the debugger can get this wrong in release builds though) i can't think what could be causing this to go wrong for me while it is fine for you. could it be my alloc implementation? could you substitute your alloc implementation with one that is default in dd, and look will problem be still re-producable? sincerely yours, george udov i've replaced my alloc implementation with that in the exalloc directory from the dwgdirect installation. if i use the quickheap code then i get an exception in a release build and crt assertions in development (below the destructor of the oddbspineptr). if i don't use the quickheap code then i get the same results as before. i've attached a zip file which should contain my libs/dlls for debug/release builds of the services using both the quickheap and standard alloc code. attached files (284.9 kb, 9 views) hi there again, is there any more news on this? i've tried to do some more searching into whats going on and have found this : the program throws the exception when trying to execute the instruction at an offset of 0x13e0 into dd_alloc.dll. this address is in a function that starts at an offset of 0x13c0 into the dll. this function is not exported from the dll and is called from the function starting at an offset of 0x1400 (odrxfree) and one other place which i am unable to determine. putting break points and couts into the debug build shows that my odrxfree implementation is never called, but the odrxalloc and odrxrealloc are. i get this output both from a debug and release build : entering my_odrxalloc, size is 24 entering my_odrxrealloc, new size is 40 old size is 24 entering my_odrxrealloc, new size is 88 old size is 40 entering my_odrxrealloc, new size is 232 old size is 88 entering my_odrxalloc, size is 40 entering my_odrxrealloc, new size is 88 old size is 40 entering my_odrxrealloc, new size is 232 old size is 88 entering my_odrxalloc, size is 24 entering my_odrxrealloc, new size is 40 old size is 24 entering my_odrxrealloc, new size is 88 old size is 40 this problem sounds similar to that posted by suming recently (sorry - i don't know how to link to that post from here) jon quote: originally posted by jon k hi there again, is there any more news on this? i've tried to do some more searching into whats going on and have found this : the program throws the exception when trying to execute the instruction at an offset of 0x13e0 into dd_alloc.dll. this address is in a function that starts at an offset of 0x13c0 into the dll. this function is not exported from the dll and is called from the function starting at an offset of 0x1400 (odrxfree) and one other place which i am unable to determine. putting break points and couts into the debug build shows that my odrxfree implementation is never called, but the odrxalloc and odrxrealloc are. i get this output both from a debug and release build : entering my_odrxalloc, size is 24 entering my_odrxrealloc, new size is 40 old size is 24 entering my_odrxrealloc, new size is 88 old size is 40 entering my_odrxrealloc, new size is 232 old size is 88 entering my_odrxalloc, size is 40 entering my_odrxrealloc, new size is 88 old size is 40 entering my_odrxrealloc, new size is 232 old size is 88 entering my_odrxalloc, size is 24 entering my_odrxrealloc, new size is 40 old size is 24 entering my_odrxrealloc, new size is 88 old size is 40 this problem sounds similar to that posted by suming recently (sorry - i don't know how to link to that post from here) jon yes, indeed it does sound like what i am getting. i have switched back to version 1.12 and it works fine. i guess i will continue using 1.12 until they can fix this bug. not really usable if it would crash every time you call the "free" function. |
所有的时间均为北京时间。 现在的时间是 01:48 AM. |