access violation

[Anonymous]

Hi all, I'm at my wit's end trying to track down a seemingly random error message. It comes up at random when I have a lot of documents that use my plugin in the system. I open a lot of databases externally if that makes a difference. I'm assuming that it's because I've left a record open somewhere but was hoping (slender hope) that someone might have some magic ideas that will help me narrow it down. I'm using VC6 sp5 and coding for Autocad 2000 - completely arx/dbx app - and I haven't been able to get debugging working. error: FATAL ERROR: Unhandled access violation reading 0x8bbe9300 Exception at 6c371381h Thank you in advance if you can offer some assistance. Best regards, Andrew

[Anonymous]

AutoCAD 2000 (not "i") uses VB5, which may cause some instability. What OS is it? If it's a NT kernel based system, then that could also cause some issues. Finding a cure for Access violations, for the most part, is like trying to drag a scared cat out from under a bed. 4 hours later, you'll end up bloody, and the cat will STILL be under the bed. -- Ben - cheesy creamy cheesy My mother called me that once.... once! ------------------------------------------------------------------------ Ben's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=201 View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797

[Anonymous]

Ben - Wake up man. You are in the ObjectARX group. :) Andrew - When you say you can't get debugging working, what do you mean exactly? I ask because it will be extremely difficult for you to track down your problem without it. -- Chuck Gabriel Since when is ignorance a point of view? ------------------------------------------------------------------------ Chuck Gabriel's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797

[Anonymous]

Whoops, transposed a "C" with a "B" there. My bad. -- Ben - cheesy creamy cheesy My mother called me that once.... once! ------------------------------------------------------------------------ Ben's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=201 View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797

[Anonymous]

Hi Chuck, I wasn't able to step through my code at that point but I've managed to get it working now though thanks to links to an article called "Debugging a release version" on msdn. Although I can't find where in my code the problem is since the actual error appears to be occurring inside MFC. First-chance exception in acad.exe (MFC42.DLL): 0xC0000005: Access Violation. At the point where the error occurs I'm not using any MFC dialogs or anything so I'm not sure where to look. I really appreciate yours and Ben's suggestions, since this is a real show stopper and the deadline's tomorrow. All the best, Andrew ----- Original Message ----- From: "Chuck Gabriel" Newsgroups: autodesk.autocad.objectarx Sent: Thursday, February 12, 2004 4:27 AM Subject: Re: access violation > > Ben - Wake up man. You are in the ObjectARX group. :) > > Andrew - When you say you can't get debugging working, what do you mean > exactly? I ask because it will be extremely difficult for you to track > down your problem without it. > > > -- > Chuck Gabriel > > Since when is ignorance a point of view? > ------------------------------------------------------------------------ > Chuck Gabriel's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 > View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797 >

[Anonymous]

Sorry, just to clarify, I'm still getting the access violation and am still panicking. When I said "I managed to get it working" I meant that I can debug now but that's not helping me a great deal. Thanks again in advance for any ideas on what I could be doing to cause an access violation in MFC. Andrew "Andrew Hoadley" wrote in message news:402a9439_2@newsprd01... > Hi Chuck, > > I wasn't able to step through my code at that point but I've managed to get > it working now though thanks to links to an article called "Debugging a > release version" on msdn. Although I can't find where in my code the problem > is since the actual error appears to be occurring inside MFC. > > First-chance exception in acad.exe (MFC42.DLL): 0xC0000005: Access > Violation. > > At the point where the error occurs I'm not using any MFC dialogs or > anything so I'm not sure where to look. > > I really appreciate yours and Ben's suggestions, since this is a real show > stopper and the deadline's tomorrow. > > All the best, > Andrew > > ----- Original Message ----- > From: "Chuck Gabriel" > Newsgroups: autodesk.autocad.objectarx > Sent: Thursday, February 12, 2004 4:27 AM > Subject: Re: access violation > > > > > > Ben - Wake up man. You are in the ObjectARX group. :) > > > > Andrew - When you say you can't get debugging working, what do you mean > > exactly? I ask because it will be extremely difficult for you to track > > down your problem without it. > > > > > > -- > > Chuck Gabriel > > > > Since when is ignorance a point of view? > > ------------------------------------------------------------------------ > > Chuck Gabriel's Profile: > http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 > > View this thread: > http://www.vbdesign.net/expresso/showthread.php?threadid=25797 > > > >

[Anonymous]

An AV can be caused by just about anything. Problems like this are usually a result of inadequate testing. In general, you need to do a lot of testing every time you make even minor code change, in order to validate that the changes didn't break something. If you adopt a more rigorus testing regime, the chances that you'll discover what code changes lead to the introduction of a bug are much better. If you spend hours revising code, and do not test, then any changes made in that time can be the cause, and that's what makes it much harder to track down. While I realize this isn't addressing your immediate need, you have to understand that the problem can be caused by any number of things, and what you've told everyone here is not nearly enough to take a wild guess about what it may be. The fact that the AV is occurring in MFC only indicates how it manifests, not where the actual bug that causes it is. When the AV occurs, what was your app doing? Does it always happen at the same point, or at different points in the application? -- AcadXTabs: MDI Document Tabs for AutoCAD http://www.acadxtabs.com AcadX for AutoCAD 2004 Beta 1 http://mysite.verizon.net/~vze2vjds/acadx/AcadX16.zip "Andrew Hoadley" wrote in message news:402aac00$1_2@newsprd01... > Sorry, just to clarify, I'm still getting the access violation and am still > panicking. > > When I said "I managed to get it working" I meant that I can debug now but > that's not helping me a great deal. > > Thanks again in advance for any ideas on what I could be doing to cause an > access violation in MFC. > > Andrew >

[Anonymous]

Hi Tony, Thanks for your reply, it's much appreciated. My app is designed to calculate sizes of water pipes in buildings. It does this by using a "project" file which contains the paths of a certain number of drawings, where each drawing is a 2d floor plan. The recalculation procedure takes all files in the project, gets the database info for them if they are in memory and loads the database from disk if they're not. This allows you to create a "virtual" 3d model from a series of flat floor plans. The error occurs when control returns to Autocad after the recalculation procedure, but the error is intermittent depending on the number of drawings in the project. It goes from happenning very rarely with 7-10 drawings to happening every single time with 20-21 drawings. Testing uncovered no problems with up to about 5 drawings, but the code has recently been expanded to cover an unlimitted (from our point of view, although not neccessarily Autocad's) number of drawings. I understand what a long shot it is when someone rocks up and says "how do I fix an access violation", but any thoughts on areas for me to look for would be most welcome. Regards, Andrew p.s. It's around 45,000 lines of code with a range of custom objects set up in DBX if that makes any difference. "Tony Tanzillo" wrote in message news:402ab036_2@newsprd01... > An AV can be caused by just about anything. > > Problems like this are usually a result of > inadequate testing. In general, you need to > do a lot of testing every time you make even > minor code change, in order to validate that > the changes didn't break something. > > If you adopt a more rigorus testing regime, > the chances that you'll discover what code > changes lead to the introduction of a bug > are much better. > > If you spend hours revising code, and do not > test, then any changes made in that time can > be the cause, and that's what makes it much > harder to track down. > > While I realize this isn't addressing your > immediate need, you have to understand that > the problem can be caused by any number of > things, and what you've told everyone here > is not nearly enough to take a wild guess > about what it may be. > > The fact that the AV is occurring in MFC only > indicates how it manifests, not where the > actual bug that causes it is. > > When the AV occurs, what was your app doing? > Does it always happen at the same point, or > at different points in the application? > > -- > AcadXTabs: MDI Document Tabs for AutoCAD > http://www.acadxtabs.com > > AcadX for AutoCAD 2004 Beta 1 > http://mysite.verizon.net/~vze2vjds/acadx/AcadX16.zip > > > "Andrew Hoadley" wrote in message news:402aac00$1_2@newsprd01... > > Sorry, just to clarify, I'm still getting the access violation and am still > > panicking. > > > > When I said "I managed to get it working" I meant that I can debug now but > > that's not helping me a great deal. > > > > Thanks again in advance for any ideas on what I could be doing to cause an > > access violation in MFC. > > > > Andrew > > > >

[Anonymous]

Hi Andrew, Some time ago I tried somthing similar (I mean opening a lot of dwgs) like so: AcDbDatabase *pDwg = new AcDbDatabase(..); es = pDwg->readDwgFile(...); //open the database and do something //do NOT pass ownership to ACAD ..... delete pDwg; and it crashed Autocad - but only after opening a number of dwgs. The number of dwgs causing the crash also depended on the dwg sizes. I concluded it was a memory (leak ?) thing. Does it make any sense to you? alex

[Anonymous]

Hi Alex, It makes far too much sense to be comfortable actually. I really hope it's an error in my code and not a leak inside Autocad. Although if it was a leak in Autocad it would explain why it's been impossible to find the error in my code... small comfort though. If it makes any difference I'm not just viewing the databases either, I'm modifying them and then using SAVEAS() to save them back to the hard drive with updated flow rates and pipe sizes. I so hope this is not an undocumented bug in Autocad. Andrew "alex" wrote in message news:402c6b7c$1_2@newsprd01... > Hi Andrew, > > Some time ago I tried somthing similar (I mean opening a lot of dwgs) like > so: > > AcDbDatabase *pDwg = new AcDbDatabase(..); > es = pDwg->readDwgFile(...); > > //open the database and do something > //do NOT pass ownership to ACAD > ..... > delete pDwg; > > and it crashed Autocad - but only after opening a number of dwgs. > The number of dwgs causing the crash also depended on the dwg sizes. > I concluded it was a memory (leak ?) thing. > > Does it make any sense to you? > > alex > >

[Anonymous]

Hi Andrew, > It makes far too much sense to be comfortable actually. I really hope it's > an error in my code and not a leak inside Autocad. Although if it was a leak > in Autocad it would explain why it's been impossible to find the error in my > code... small comfort though. I even tried to discover memory leaks using an external tool.(Sysinternals DebugView) but it didn't detect any. > If it makes any difference I'm not just viewing the databases either, I'm > modifying them and then using SAVEAS() to save them back to the hard drive > with updated flow rates and pipe sizes. I don't think it matters what you do with the db, as long as you do it properly and in a rule-abiding, god-fearing manner -:). > I so hope this is not an undocumented bug in Autocad. We all do. It would be nice to hear something from the Autocad people about this, or maybe from the gurus. BTW, did you notice that Autodesk staff involvement in this group has thinned out in the last few months? Please let me know if you discover anything on the subject. I'll do the same. alex

[Anonymous]

I believe that there is a boolean input flag to the AcDbDatabase constructor, whether it should build a complete database or not. I think that you should pass 'false' if you intend to use readDwgFile. This is from the top of my head - I don't have the docs here. Good Luck! Henrik Vallgren www.stream-space.com > "alex" wrote in message news:402c6b7c$1_2@newsprd01... > > Hi Andrew, > > > > Some time ago I tried somthing similar (I mean opening a lot of dwgs) like > > so: > > > > AcDbDatabase *pDwg = new AcDbDatabase(..); > > es = pDwg->readDwgFile(...); > > > > //open the database and do something > > //do NOT pass ownership to ACAD > > ..... > > delete pDwg; > > > > and it crashed Autocad - but only after opening a number of dwgs. > > The number of dwgs causing the crash also depended on the dwg sizes. > > I concluded it was a memory (leak ?) thing. > > > > Does it make any sense to you? > > > > alex > > > > > >

[Anonymous]

Hi Henrik, You are right and we (at least I) certainly did it like the docs say - and it throws exceptions nevertheless. I didn't want to clutter my massage so I omitted the inputs. alex "Henrik Vallgren" wrote in message news:402e75bd$1_1@newsprd01... > I believe that there is a boolean input flag to the AcDbDatabase > constructor, whether it should build a complete database or not. I think > that you should pass 'false' if you intend to use readDwgFile. This is from > the top of my head - I don't have the docs here. > > Good Luck! > > Henrik Vallgren > www.stream-space.com >

[Anonymous]

I can say with a fair degree of confidence that the issue is not related to opening and saving multiple databases. I have used AcDbDatabase::readDwgFile() and AcDbDatabase::saveAs() to batch process around 7500 drawings at a time without a hiccup. However, depending on what you are doing with the drawings, you may run into some problems with older drawing (R13 and older). At least that was my experience. I wrapped my code for saving the drawing in a try/catch(...) block, so I could abort in a controlled manner if anything went wrong with the save. I hope you get it all sorted out in time. Happy hunting. -- Chuck Gabriel Since when is ignorance a point of view? ------------------------------------------------------------------------ Chuck Gabriel's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797

[Anonymous]

Hi Chuck, When you batch process these drawings, would there only be one drawing in memory at a time? ie I wonder if there's a difference with the fact that I am loading up to 20 or more of them concurrently Still no joy, but very much appreciating the feedback. Thanks (and thanks also to others - Alex in particular) Andrew "Chuck Gabriel" wrote in message news:Chuck.Gabriel.11odem@vbdesign.net... > > I can say with a fair degree of confidence that the issue is not related > to opening and saving multiple databases. I have used > AcDbDatabase::readDwgFile() and AcDbDatabase::saveAs() to batch process > around 7500 drawings at a time without a hiccup. However, depending on > what you are doing with the drawings, you may run into some problems > with older drawing (R13 and older). At least that was my experience. > I wrapped my code for saving the drawing in a try/catch(...) block, so > I could abort in a controlled manner if anything went wrong with the > save. > > I hope you get it all sorted out in time. Happy hunting. > > > -- > Chuck Gabriel > > Since when is ignorance a point of view? > ------------------------------------------------------------------------ > Chuck Gabriel's Profile: http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 > View this thread: http://www.vbdesign.net/expresso/showthread.php?threadid=25797 >

[Anonymous]

I never had more than two databases open at any given time, but I am still not inclined to believe that opening and closing AcDbDatabase objects is the source of your exception. Did you try wrapping the open and close functions in try/catch blocks? "Andrew Hoadley" wrote in message news:4031e413_2@newsprd01... > Hi Chuck, > > When you batch process these drawings, would there only be one drawing in > memory at a time? > > ie I wonder if there's a difference with the fact that I am loading up to 20 > or more of them concurrently > > Still no joy, but very much appreciating the feedback. Thanks (and thanks > also to others - Alex in particular) > > Andrew > > > "Chuck Gabriel" wrote in message > news:Chuck.Gabriel.11odem@vbdesign.net... > > > > I can say with a fair degree of confidence that the issue is not related > > to opening and saving multiple databases. I have used > > AcDbDatabase::readDwgFile() and AcDbDatabase::saveAs() to batch process > > around 7500 drawings at a time without a hiccup. However, depending on > > what you are doing with the drawings, you may run into some problems > > with older drawing (R13 and older). At least that was my experience. > > I wrapped my code for saving the drawing in a try/catch(...) block, so > > I could abort in a controlled manner if anything went wrong with the > > save. > > > > I hope you get it all sorted out in time. Happy hunting. > > > > > > -- > > Chuck Gabriel > > > > Since when is ignorance a point of view? > > ------------------------------------------------------------------------ > > Chuck Gabriel's Profile: > http://www.vbdesign.net/expresso/member.php?action=getinfo&userid=16 > > View this thread: > http://www.vbdesign.net/expresso/showthread.php?threadid=25797 > > > >

[Anonymous]

> You are right and we (at least I) certainly did it like the docs say - and > it throws exceptions nevertheless. > I didn't want to clutter my massage so I omitted the inputs. We've had tons of trouble in this space. 1. Make sure you maintain/restore the "current working database". We found that many methods fiddle around with this, despite claiming that they dont. 2. Watch the content of the drawing files you are opening - I think its AcDbOleFrame that has a known bug where AutoCAD "defers" a fixup of the object till the next time the command-line is reached. If you close the file before it gets there, then it crashes.

[Anonymous]

HI Jeff, Could you elaborate,(particularly on your 1st)? Thanks, alex "Jeff Laing" wrote in message news:40452668$1_3@newsprd01... > We've had tons of trouble in this space. > > 1. Make sure you maintain/restore the "current working database". We > found that many methods fiddle around with this, despite claiming that they > dont. > > 2. Watch the content of the drawing files you are opening - I think its > AcDbOleFrame that has a known bug where AutoCAD "defers" a fixup of the > object till the next time the command-line is reached. If you close the > file before it gets there, then it crashes. > >