Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Local Dim causes the compiler to crash

Author
Message
anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 11th Jul 2011 12:31
This works


while this causes the app to crash



As you can tell, it's a user-defined type. However, the definition of the type is at the beginning of the application - in the main startup file - defined before anything else that might use reference it actually reference it.

I just found this to be highly odd, because I swear I've defined arrays in functions with "local dim" before....
Lucas Tiridath
AGK Developer
17
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 11th Jul 2011 12:52
I think DBP arrays are always global so local should not work anyway. That said, my arrays don't crash if I put local there. When does it crash?

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Jul 2011 12:58
The LOCAL keyword absolutely does work with arrays, and works correctly too.

For instance, the following code will NOT compile, unless the LOCAL keyword is taken out.


@anwserman,
You may need to post a little more code.

anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 11th Jul 2011 13:02
Here is the code that defines my UDT's, which once again is in the main startup module.



and here is the code that I use the local array for....



If I change that one line to local dim, it crashes
Max P
16
Years of Service
User Offline
Joined: 23rd Jan 2010
Location:
Posted: 11th Jul 2011 13:08
I think
should be
, not sure though.
anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 11th Jul 2011 13:17
UNDIM deletes the array and its contents, you'd use this to delete an array that has been converted into a pointer reference.

UNLINK keeps the array in memory, but you need to LINK it up to another array before you can use it with traditional DB commands.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Jul 2011 13:29
@Max P,
He's doing some stuff with arrays that you may not immediately see.

He creates a local array and populates it. He's then getting a pointer to the array, storing it, and then finally disconnecting the array data from the array variable so that it doesn't get freed at the end of the function.

At a later point, he can reconnect the pointer to another array to access it.

@anwserman,
I've pasted the two sections of code together (after hacking out the vector types and DarkData stuff which I don't have) and it works correctly (that isn't meant to be a pointing finger at DarkData either - it's an 'I don't know').

anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 11th Jul 2011 13:35
@IanM
It shouldn't be a DarkData issue, as if I remove all of the code except the 'local dim' line, it still crashes >_>

I'll just take what I can get, it runs anyway. And if its in a function, it should by default be local. :3

Thanks again IanM! BTW, your plugins still rock.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Jul 2011 18:55
Quote: "And if its in a function, it should by default be local"

Unfortunately not. For every variable type except arrays, that's true. It used to be true for arrays too, but Lee changed it when people requested it.

Do you have a crash file in the same directory as your executable? (I forget exactly what DBPro calls it, but it starts with 'Crash' and contains the current date). If you do, then you can open that file in a text editor, and somewhere in there it has the line number the crash occurred on.

anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 12th Jul 2011 05:15 Edited at: 12th Jul 2011 05:43
Nope, no data pertaining to the crash.
I just searched all of my code for anything that contains 'tArray' in it. Changed one variable scope to local (changed "dim tArray()" to "local dim tArray()"), but it still crashes.

I did some screwing around, and it appears that if I define a non UDT at that line of code, the program works. So,...



Works and doesn't crash. However,



causes it to crash and burn. Now, if I get rid of the "local", the code compiles and works as expected to. But it crashes when "local" is placed in there. I did a 'slow program' in the step-by-step debug mode, and watched it go through each line until it choked on "S4_FXAnimation".

So, something is causing it to not like the UDT in this function, at least when declared as local. And it's odd, because the UDT is declared at the top of the first file that gets run.

Also, no debug info that I can see. Is it in the project directory or elsewhere?

And why the heck aren't local variable arrays... local? It kinda breaks with the assumption that something declared in an array stays in the array.
anwserman
15
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 12th Jul 2011 08:15 Edited at: 12th Jul 2011 08:18
Solved. Again.
This was similar to a problem that I experienced before. Guess, what causes the code to work without any problems?


Yup. Declaring a variable of a non UDT before the code that was causing hiccups. Besides adding a 'local' to another declaration elsewhere (and that didn't solve the problem either), all I did was change the order of local variable declarations.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th Jul 2011 14:52
That sounds like a corrupted stack is the issue, which puts the blame on the compiler if that's the case.

Login to post a reply

Server time is: 2026-07-10 21:41:54
Your offset time is: 2026-07-10 21:41:54