Found Bug, Dialogue

[J B Wood (Zumwalt)]

This used to work:

Code Select Expand



#include "Dialog.src"

global sub main()
{
dlg d1;
d1.Create(0,0,300,202,0x80C80080,0,"Aurora!",0);
d1.AddControl(CTSTATIC,"Aurora Demos",10,6,70,16,0x5000010B,0x0,STATIC_1);
d1.AddControl(CTBUTTON,"Tank",11,31,70,20,0x5000000B,0x0,BUTTON_2);
d1.DoModal();
return 0;
}


Then it was telling me missing call stack.
So, then I changed the code to:

Code Select Expand


#include "Dialog.src"

global sub main()
{
'dlg d1;
'd1.Create(0,0,300,202,0x80C80080,0,"Aurora!",0);
'd1.AddControl(CTSTATIC,"Aurora Demos",10,6,70,16,0x5000010B,0x0,STATIC_1);
'd1.AddControl(CTBUTTON,"Tank",11,31,70,20,0x5000000B,0x0,BUTTON_2);
'd1.DoModal();
return 0;
}


Get this, the dialogue loaded.. ok this was wierd, because I remembered at just that moment that ' is rem for basic, not Aurora, so why it worked I don't know. Then I went ahead and removed the ' from the code.. then everything still worked and I couldn't reproduce the error.

Bugger. Well its working now.

[Parker]

For one, it's bad practice to #include other source files

' is part of a lexer sequence that requires a single character inside of two ' marks. If it can't find a 'c' sequence where c is any ascii character, then ' issues an "invalid character" warning and is ignored.

Maybe a file was corrupted in the first build, that's sometimes the case when you can't reproduce a crash. I couldn't tell you anything further without seeing Dialog.src.

[J B Wood (Zumwalt)]

Code Select Expand


#define STATIC_1 1
#define BUTTON_2 2
#include "TankGame.inc"
class dlg:CDialog
{
declare OnInitDialog(),int;
declare OnClose(),int;
declare OnControl(int nID, int nNotifyCode, unsigned int hControl),int;
}

dlg::OnClose(),int
{
CloseDialog(1);
return true;
}

dlg::OnInitDialog(),int
{
/* Initialize any controls here */
CenterWindow();
return true;
}

dlg::OnControl(int nID, int nNotifyCode, unsigned int hControl),int
{
select nID
{
case BUTTON_2:
if(nNotifyCode = 0)
{
Game();
/*button clicked*/
}
}
return true;
}



[Parker]

Looks normal to me... if you are still having errors though, try doing a debug build and find where it crashes.

[J B Wood (Zumwalt)]

Forget debug build, that new debug interface is killing me since I have methods with the same name in different classes. Debug doesn't like that.

[Todd Riggins]

Forget debug build, that new debug interface is killing me since I have methods with the same name in different classes. Debug doesn't like that.

Thanks not good to hear. Thanks for the heads up. 

[Ionic Wind Support Team]

That shouldn't make a difference.  The entire name of the method includes the class name.

[Ionic Wind Support Team]

Zumwalt,
Elaborate more if you please.  Just a simple test but this works fine under the debugger:

Code Select Expand


class classone
{
declare blah();
}

class classtwo
{
declare blah();
}

classone::blah()
{
int a = 8;
float b = 85;
#break;
}

classtwo::blah()
{
int zz=99;
#break;
}

sub main()
{
classone c1;
classtwo c2;

c1.Blah();
c2.blah();
}


The call stack properly shows classone@blah during the first break and classtwo@blah during the second.  Locals work in both cases as well.  So I need to know specifics if I am going to improve on it

[J B Wood (Zumwalt)]

I took your code verbatim, made a src file and pasted it.
Did a single build as a windows.exe, changed project type to debug build checked off.
Compiled and boom, killed the app with the following information:
AppName: aurora1.exe    AppVer: 0.0.0.0    ModName: aurora1.exe
ModVer: 0.0.0.0    Offset: 0000b091

More information:
0040B090  int         3    (disassembly break line)

Where the line exists:
classone::blah()
{
0040B06C  lea         eax,[ebp-4]
0040B06F  mov         esi,eax
0040B071  mov         eax,8
0040B076  mov         edx,eax
0040B078  mov         dword ptr [esi],edx
   int a = 8;
0040B07A  lea         eax,[ebp-8]
0040B07D  mov         esi,eax
0040B07F  mov         eax,55h
0040B084  mov         edx,eax
0040B086  push        edx 
0040B087  fild        dword ptr [esp]
0040B08A  fstp        dword ptr [esp]
0040B08D  pop         edx 
0040B08E  mov         dword ptr [esi],edx
   float b = 85;
0040B090  int         3    <-- here is the spot that the assembler stops at
   #break;
}

[Ionic Wind Support Team]

Works fine here.  int 3 is a break command, that is what #break outputs.

After its built you have to select build->debug->start.  Or click the little bug icon.

you can't just execute a debug build, int 3 causes the system to search for a debugger if it is not already running under a debugger.

[J B Wood (Zumwalt)]

Probably my problem then, I had it to execute after build which is what I always have it set to.
Good to know the change.
Now back to eating up my 2 gig of memory trying to create 65535 clients at the same time in a loop connecting to my little server.

[J B Wood (Zumwalt)]

New info on this, I just tried to do a #break; in my class, this is a project vs stand alone, so I am not trying to compile and execute, but just compile in debug.

I get the following error:

Linking...
Aurora Linker v1.0 (etc)
Error: Duplicate public symbol Game
Error: Duplicate public symbol Terminate
Error(s) in linking Aurora3D.exe

[Ionic Wind Support Team]

Independant functions, not class methods, need to be uniquely named.

You have two functions named 'game' then.  And two functions named 'Terminate'.   Probably in an include file somewhere.  Or you have those functions in an include file and are including that file twice.  Which is why we always recommend that include files should not contain any executed code.  Just definitions, constants, class definitions, etc.

[J B Wood (Zumwalt)]

I went through all of my src and inc files, I only have 1 game sub and 1 terminate sub, I also checked for any other src that might be inheriting the inc file with the 2 subs, none found.

To get around this once I started to think about how your new debug worked, I just created a new class and made those 2 subs methods of the class. That got rid of the problem. Just no global subs in my projects, thats ok. Probably stupid to do anyway.

Running into an access violation error now on something else, has nothing to do with the debugger, so its probably a pointer issue.

[Ionic Wind Support Team]

From some of the code you posted I suspect you probably hade the 'game' function in a file that was #included.  Which is not how you make functions visible to more than one source file in your project.  Learn what the GLOBAL and EXTERN keywords do.

When you make a function GLOBAL

//file1.src
GLOBAL SUB Game()
{
...
}

The name gets added to the linkers list of visible functions, meanining you can access that function from another source file without having to #include it.  Anywhere else in your project you just declare it as an external

//file2.src
declare extern Game();

sub SomeFunction()
{
      Game();
}

Both of those files are added to the project, not into an include file.  The linker handles the rest.  When it sees the function call it is noted as an 'unresolved external' and then searches through all of the other object files for a match.  Since you made the function GLOBAL it finds a match and continues with creating the executable.

When building a debug executable all functions like this are made global, as that is what is needed to display local variables, and I mentioned that in the update announcement too.  Think of it as Aurora helping you to design a better program.

Paul.

[J B Wood (Zumwalt)]

Not to be a bugger about it, but the sub Game() was in a SRC file that was included in the project and was not #include anywhere.

In another src I called Game(), the fact that sub Game() was in a src but not declared Global Sub Game() seemed to make it assumed global. That beside the point, there was no need to have Game() be a global sub anyway, since I might not always want to instansiate the sub.

Placing it as a child method to a class for the Tank was fine for its purpose. I appreciate the explinations, they help with further learning the language.

The problem I am running into at the moment has nothing to do with the Game() anymore, its dealing with the RakNet wrapper and its routines. I have emails into the gentlemen that is helping me with it to see if he has any more suggestions on this particular issue.

Talking about the debugger though since you brought up local variables, when I place a #break in a method, then I create an instance of the class that holds the method, compile as a debug compile then debug step through, it stops correctly in the code. However, as I step through, the local variables are not displayed on the Locals tab. Global variables are no where to be found in the debugger, and I have to use my own OutputDebugStringA declare to get the results of the variables to show up in the debug window at the bottom since it is not in the debug window that pops up with the tabs during a debug step through.

The access violation seems external to the Aurora project itself, so that one is going to be harsh to track down since it has to do with a 3rd party DLL which wraps the RakNet library and exposes its methods. The wrapper works in other engines based on how they would use it, I own the .Net code for the wrapper, so now its a matter of time to track down that issue.

There are rules that go for the Aurora Debugger that I don't fully understand yet but am getting used to.
Here is the code block where the global variables are not visible unless I debug print them:

Code Select Expand


NetworkServer :: initServer()
{
#break;
Server=RN_GetRakServerInterface();
OutputDebugStringA(STR$(Server));
Result=RN_ServerStart(Server,8,0,0,60069);
OutputDebugStringA(STR$(Result));
RN_ServerStartOccasionalPing(Server);
RN_ServerSetRelayStaticClientData(Server,1);
BitStream=RN_BitStreamCreate1(0);
ID_MOUSE_UPDATE = 100;
}


At one point in its life I had those variables local instead of global, but they still didn't show up in my local for some reason, probably something strange I am doing. Anyway, like I stated, to get around that I just added the OutputDebugStringA declare then used it to see my results.

[Ionic Wind Support Team]

Do you see a 'Global' tab in that display?  No because global variables are not displayed yet.  It says 'Locals'.  Thought I made that pretty clear but I guess I'll need to change the tab to "locals not globals", and the forth tab which is turned off to "globals not locals"

It is a beta, and the disclaimer is "use at your own risk".  Not everything is completed, not everything is fully working just yet. 

Not to be a bugger about it, but the sub Game() was in a SRC file that was included in the project and was not #include anywhere

Not to be a bugger myself but in your own code that you posted you have a #include for a source file.  And that source file included code and another include file. 

#include "Dialog.src"

Which is both Parker and I mentioned that you shouldn't be doing that.  And why I was making the guess you might have been doing it somewhere else in the project. 

The linker does not lie, it only reports what it finds in your object files.  So in two separate object files it found two functions named "Game" and two functions named "Terminate".  Meaning they were compiled twice somewhere and the usual culprit is #include. 

And the linker complains for a reason

[J B Wood (Zumwalt)]

After I seen about the #include on the "dialogue.src" I removed it, PRIOR to having this problem, but I can see where you might have 'assumed' I had still done that. So the #include on the src didn't relate to my problem.
Anyway, its all change at this point, as I had stated I redid the methods and made them children to another class.
I know globals are no where to be found, neither are locals in the case of my debugs. I also know its a 'use at your own risk', and I use it.

You could actually change the "Locals" to be totally clear during the beta to "Possibly Locals Here", and then make a 4'th tab of "You wish it was Globals" :)ÂÃ, 

What the linker does or doesn't do is beyond my knowledge. All I know is from time to time the linker says it can't compile and I have to quit out of the app and go back in to compile and it compiles. Other times the linker bombs on different files that it had no problems with prior, so I quit out, delete all the asm files and o files and go back in and compile. The ones I really hate is when I am working in the compiler for like a few hours then it says can't find the file at a desktop location, those urk me.

Now, I'll head off and burry my head back under the pointer rock it was under.

Changes to the code after sub change, but with sub in place, Aurora1.src change was consistant with your and parkers suggestion on the src.
Aurora1.src

Code Select Expand


#include "Dialog.inc"
#include "rakknet.inc"
#typedef UINT unsigned int
#typedef BOOL int
#typedef LONG int
#typedef DWORD unsigned int
global sub main()
{
NetworkServer myServer;
myServer.initServer();
MessageBox(NULL,STR$(Server),"Result");

dlg d1;
d1.Create(0,0,300,202,0x80C80080,0,"Aurora!",0);
d1.AddControl(CTSTATIC,"Aurora Demos",10,6,70,16,0x5000010B,0x0,STATIC_1);
d1.AddControl(CTBUTTON,"Tank",11,31,70,20,0x5000000B,0x0,BUTTON_2);
d1.DoModal();
return 0;
}


Dialog.src

Code Select Expand


#include "Tank.inc"
#include "Dialog.inc"

dlg::OnClose(),int
{
CloseDialog(1);
return true;
}

dlg::OnInitDialog(),int
{
/* Initialize any controls here */
CenterWindow();
return true;
}

dlg::OnControl(int nID, int nNotifyCode, unsigned int hControl),int
{
TANK tankGame;
select nID
{
case BUTTON_2:
if(nNotifyCode = 0)
{
tankGame.Game();
/*button clicked*/
}
}
return true;
}


Dialog.inc

Code Select Expand


#define STATIC_1 1
#define BUTTON_2 2

class dlg:CDialog
{
declare OnInitDialog(),int;
declare OnClose(),int;
declare OnControl(int nID, int nNotifyCode, unsigned int hControl),int;
}


[Ionic Wind Support Team]

I am just trying to be helpful.  So far I haven't encountered a place where local variables are not displayed, which is why it is helpful if I can duplicated it.  So the tab remains "Locals" for now. 

I've never had to delete an object file either in the hundreds of projects I compile, nor has anyone else reported that particular problem.  But I am sure I will run into it eventually.  The only common one that I already knew about was the linker not being able to create an executable and having to close the IDE and reopen.  Which isn't a problem of the linker...

The IDE has a synchronization problem when building a debug executable, and you have a syntax error, where previously you had successfully created an executable, then you correct the error and try to compile.  The first thing the IDE does for each build is delete the old .exe before compiling all files.  For some reason the delete sometimes fails and the system keeps a file lock on the executables file name.  The linker then tries to create the executable and can't open the file as Windows still has a lock from the IDE.  So that one I am still trying to track down which isn't an easy thing as the delete command returns success regardless.

Paul.

[John Syl.]

Zumwalt,
I found if your source file is not in the project directory or
you have the "relocation table included in the executable" box, ticked, then local variables will not be displayed.

hth
John

[J B Wood (Zumwalt)]

Thanks, going to look into that setting.
By the way, what is hth?

[Parker]

http://www.acronymfinder.com/af-query.asp?Acronym=hth&Find=find&string=exact

[Ionic Wind Support Team]

Having a relocation table prevents line number/file information from ending up in the executable.  So the debugger can't single step or show variables.  The call stack only shows the function name and not the source file.

That is just a matter of documentation.

[Parker]

What exactly does a relocation table do?

[Ionic Wind Support Team]

It's for DLL's mainly and allows the system to relocate a DLL in memory.  However I was requested to add it for executables since you can also dynamically load an EXE and get exported functions to work.