• ### Popular Now

• 13
• 18
• 19
• 27
• 10

#### Archived

This topic is now archived and is closed to further replies.

# Trouble tracking down error.

This topic is 5107 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''ve been trying to code a method to draw the silhouette outline of an object given a point light source. Stopped at exception c0000005: accessviolation at 0x0040374e: read of address 0xc02069e The line of C++ that causes it is glNewList(draw_silhouette_list, GL_COMPILE_ANDEXECUTE); According to the debugger the equivalent assembly is: push 0x00001301 mov eax, [ebx+0x18] push eax call 0x00416c0e The exception specifically occurs at: mov eax, [ebx+0x18] This is the code fragment surrounding the erroneus line:
    else{
calcsilhouette(light);
POINT3f  a, b;
glNewList(draw_silhouette_list,GL_COMPILE_AND_EXECUTE);
glBegin(GL_LINES);

What is confusing me is that if i comment out the line calcsilhouette(light); The exception does not occur, the project builds, and the program runs fine, except that since no silhouettes are calculated, thus none are drawn. Using the debugger, I''ve concluded that something seriously wrong happens once the program leaves the final closing brace in the calcsilhouette function. When the program returns to it, all of the member data, incuding the this pointer are all changed. Thus the access violation error
void OBJECT::calcsilhouette(LIGHT* light){
/*DELETE ALL ELEMENTS*/
//edge_list->reset();

delete edge_list;
/*CULL FACES AWAY FROM LIGHT*/

/*compute vector from polygon to light*/
POINT3f lightt = light->position - poly_cur->data->points[0];

/*IF IT PASSES ADD EDGES TO EDGELIST*/
bool e0 = false, e1 = false, e2 = false;
EDGE edge0(poly_cur->data->points[0], poly_cur->data->points[1]);
EDGE edge1(poly_cur->data->points[1], poly_cur->data->points[2]);
EDGE edge2(poly_cur->data->points[2], poly_cur->data->points[0]);
/*USE OVERLOADED OPERATOR TO COMPUTE DOTPRODUCT*/
if(lightt * poly_cur->data->normal > 0){
e0=e1=e2=true;
break;

if( *edge_cur->data==edge0 ){
e0 = false;
edge_list->removeNode(edge_cur);
}
if( *edge_cur->data==edge1 ){
e1 = false;
edge_list->removeNode(edge_cur);
}
if( *edge_cur->data==edge2 ){
e2 = false;
edge_list->removeNode(edge_cur);
}
}*/
}
if(e0)
if(e1)
if(e2)
}
}
Although its probably not algorithmically correct yet, I want to correct it memory wise. The pointer edge_list points to a templated linked list. The rest method is as follows:
template <typename T>
}

delete destroys the node pointer head which recusively destroys the rest of the list.
template <typename T>
NODE<T>::~NODE(){
if(next!=NULL)
delete next;
if(data!=NULL)
delete data;
}

Yes, I know I could be using the standard list library, but I''ve created my own as a learning expirence. (which it has been so far) If the code fragments arn''t enough, I''m willing to supply more.(this post is big enough already ) I hope its some silly mistake rather than a fundamental flaw. I''ve spend to last two weeks of my free time trying to solve it, I hope some one here has the insight that I lack. Thankyou very much in advance.

##### Share on other sites
2) Access violations are generally caused by a) accessing a NULL pointer (obviously not the case here), b) writing over array boundaries, c) writing over array boundaries into not yet allocated memory space, which doesn''t neccessarily cause an exception to be generated, but could cause the program to halt later when either that memory is being allocated or in some other perfectly legal case (this is pretty much implementation specific).
3) This is what the debugger is for.

That is, do not look at the code and hope to find the mistake (you''d usually have to be very very patient or very very lucky). Run the program from the compiler in debug mode: first see where the program crashes, then try setting breakpoints and watches to identify which variables are failing you. MSVC and BCB both have a very nice integrated debuggers, which usually (but not always) tell you what the problem is (actually they don''t tell you, but they''re rather handy to use regardless). If you don''t know how to set watches and breakpoints (or what they are), post here again and someone will try to elaborate a little.

In general, it''s not wise to ask others to do debugging for you because no one really wants to as this is one of the most menial tasks in programming and you''ll find that almost no one will be willing to delve in your source code voluntarily.

"Finishing in second place, simply means you are the first loser." - PouyaCat

##### Share on other sites
The problem is that I have been debugging (or trying to). I''m using borland''s BuilderX for the debugging. I have set breakpoints and watches. That confuses me the most is that all of the member variables in the OBJECT disenegrate on the final closing brace of calcsilhouette. The this pointer, EVerything. And thhen when glNewList tries to access draw_silhouette_list, the program crashes because draw_silhouette_list is corrupted.

This is my first time trying to track down a memory error using a debugger. I started out this project using notepad and borland''s commandline compiler, this problem would be impossible to trackdown without a debugger, and its become very hard with one.

##### Share on other sites
http://www.fluidstudios.com/pub/FluidStudios/MemoryManagers/
See if it tells you about any out of bounds memory overwrites

[edited by - m_e_my_self on March 26, 2004 11:02:35 AM]

##### Share on other sites
Mmkay - I just had a look at your source code and I must say I didn''t understand much. I mean, it''s somewhat logical given what you''re trying to do, but taken out of context and being not my code, it''s pretty difficult to debug. So, here''s a few more hints that I can think of:

1) You know when the program fails - this is a good thing (you know that OBJECT is a mangled mess at the end of calcsilhouette() ). Watch the OBJECT evolve throughout the function and identify precisely where something goes wrong. Since you''re dealing with linked lists, this could be a simple bug in the list code. Make sure you''ve got your allocations-deallocations-linking correct.
2) Trace the number of elements in the edge list.
3) Never and I mean NEVER EVER write delete edge_list; in your code. Always make it something like if(edge_list) delete edge_list;.
4) What precisely does the debugger tell you about the OBJECT structure as it leaves calcsilhouette()? Is it all NULL''s or are the values random or some recurring values such as 0xcdcdcdcd?
5) Comment out parts of the code you feel can contain errors - this is actually the most reliable (alas, the stupidest) means of finding the bug.

Hope this helps.

"Finishing in second place, simply means you are the first loser." - PouyaCat