IDE = Error in code, Compile/run = no errors.

[jassing]

I have this bit of code: (partial only)

Code: Select all

Procedure RegReadDWord(section,path$,key$)
	Protected value=-1,tmp, datasize=4  ;datasize.l=4 ; 4 bytes = 32 bits (long).
  If RegOpenKeyEx_(section,path$,0,#KEY_READ,@tmp)=#ERROR_SUCCESS

The last line 100% crashes in the IDE when run.



But if I compile it -- it runs fine/as expected.

-josh

NB: I tried to use the stand alone debugger and compile from the command line -- but it starts my exe, says "waiting for exe to start" then my exe crashes & the debugger reports "terminated unexpectedly" (But, this happens with any exe I try to use the external debugger)

[Trond]

In 99999 out of 100000 cases this means just one thing: Your code has a bug. Pure luck may prevent it from showing up without the debugger, but the problem is there, just waiting to show up at the most inconvenient time - better fix it now.

[jassing]

the program is a command line tool; and was stress tested by running over 100,000 times on several computers. No error. Works exactly as expected.

So if there's an error that only shows up wtih teh debugger -- then logic would say "use no debugger, no error" -- but this is not the case. always errors in the ide.

So if there is an error, it's elusive; and all values are correct (by looking at the variables) -- and since I can't use a debugger on the .exe, I don't know how to check the differences between ide run and command line run -- any suggestions on where to look for the error?

[Trond]

So if there is an error, it's elusive; and all values are correct (by looking at the variables) -- and since I can't use a debugger on the .exe, I don't know how to check the differences between ide run and command line run -- any suggestions on where to look for the error?

You don't want to bother with examining the case where it runs without a crash. You must reproduce the crash to fix it.
Looking for the error depends on many things. The first thing to check for is whether the code always crashes in the same place. If not, hunting down the bug will be a lot harder.

If the crash always occurs on the same line (RegOpenKeyEx_()) it is very likely that one of the parameters are wrong. For a start, correct it so that you send the address of the string:

Code: Select all

If RegOpenKeyEx_(section, @path$, 0, #KEY_READ, @tmp) = #ERROR_SUCCESS

Apart from that it's difficult to say what could be wrong with it. I assume you are on a 32-bit system, else almost everything would be wrong with your code. You could also try to run it with the Purifier to catch errors earlier.

[jassing]

]You don't want to bother with examining the case where it runs without a crash. You must reproduce the crash to fix it.

Yes, but the ONLY way it crashes is via the IDE. That's it. period. end of story. It cannot be replicated otherwise.
THAT is the problem...

The first thing to check for is whether the code always crashes in the same place.

Only there, that line, the same msg, each and everytime it's run via the ide... I run the exe, no error.

You could also try to run it with the Purifier to catch errors earlier.

Purifier is enabled.. didn't alert me of anything...

thanks anyway.

-j

[jassing]

Using the ide's debugger, I get the values used to call the wrapper function... That runs fine in the ide, when run on it's own.
I'm open to corrupting memory somewhere, but the function(s) are not being declared twice, I've taken out hte one allocatememory() command...
Tre frustrating...

Code: Select all

Procedure RegReadDWord(section,path$,key$)
	Protected value=-1,tmp, datasize=4  ;datasize.l=4 ; 4 bytes = 32 bits (long).
  If RegOpenKeyEx_(section,path$,0,#KEY_READ,@tmp)=#ERROR_SUCCESS
    If RegQueryValueEx_(tmp,key$,0,0,@value,@datasize)<>#ERROR_SUCCESS : value=-1 : EndIf
    RegCloseKey_(tmp)
  EndIf
  ProcedureReturn value
EndProcedure

section = 80000001
path$ = "software/netlib/nlSecure/Debug"
key$ = "enable"

Debug RegReadDWord(section,path$, key$)

[Trond]

How do you get the value of section? A hardcoded number of 80000001 is wrong.
How do you set the value of path? The current value is wrong. On Windows, paths are separated by \'s, never /'s.
Why didn't you add the @?

Code: Select all

Procedure RegReadDWord(section,path$,key$)
  Protected value.l=-1, tmp, datasize=SizeOf(value)
  If RegOpenKeyEx_(section, @path$, 0, #KEY_READ, @tmp)=#ERROR_SUCCESS
    If RegQueryValueEx_(tmp, @key$, 0, 0, @value, @datasize)<>#ERROR_SUCCESS : value=-1 : EndIf
    RegCloseKey_(tmp)
  EndIf
  ProcedureReturn value
EndProcedure

Debug RegReadDWord(#HKEY_CURRENT_USER, "Software\Microsoft\Windows\CurrentVersion\Explorer", "Shutdown Setting")

[jassing]

Doesn't explain the fact that when compiled & run as a exe the code works exactly as expected.
When run in the ide, it errors.
Your points are taken; but I don't understand why one works and one doesn't... I would expect similar results.

I copied your exact code & replaced mine. I changed the / to \ -- I changed the hive to quad.
I checked by
debug #hkey_Current_user
debug section
(Changing it to quad got it to be the same #)
Still it errors in the ide, and runs thru as expected when compiled.

[Trond]

Your points are taken; but I don't understand why one works and one doesn't... I would expect similar results.

When you allocate memory, you rarely get exactly the amount you allocated. Often you get slightly more (this has to do with the page size, which is 4096 bytes). So writing or reading past the allocated memory doesn't trigger an error because the buffer was larger than assumed.
The same concept applies when two allocations are done in order. Memory area 2 may then end up right after memory area 1, and reading/writing past memory area 1 won't give an error, because you're in the allocated memory area 2.

That's two ways a program bug "disappears" in some situations.

Apart from that I can't help you, as it seems the error is in a different part of the program.

Edit: What I do when I have a mystic error like this, is to make a copy of the whole project, then deleting large portions of the program until the problem disappears. When it disappear I add back what I deleted last. This way you're practically guaranteed to end up with a small code that causes the error.

[C64]

I use the same RegReadDWord procedure as you, but I still have datasize.l=4 and you have dropped the ".l" which makes it an integer type (".i" by default). Why did you do that? Does it still crash if you change it back to a long like it's supposed to be?

[jassing]

Apart from that I can't help you, as it seems the error is in a different part of the program.

That's two ways a program bug "disappears" in some situations.

It's 100% of the time -- if it were a paging issue -- I'd expect to see the issue randomly. But each and everytime I call that api with verified proper parameters, it crashes in the ide - never in the runtime. This is on hundreds of test runs. Verified on 3 computers.

Edit: What I do when I have a mystic error like this, is to make a copy of the whole project, then deleting large portions of the program until the problem disappears.

Looks like that's my next step since I can't get the external debugger working...

Thanks for the advice.
-j

[Trond]

Apart from that I can't help you, as it seems the error is in a different part of the program.

That's two ways a program bug "disappears" in some situations.

It's 100% of the time -- if it were a paging issue -- I'd expect to see the issue randomly.

It's not a "paging issue" in that paging is working correctly, it just doesn't catch all errors. I'd expect the problem to be just like this. But it can also happen in reverse (runs only correct with debugger), then it's a real nightmare.

But each and everytime I call that api with verified proper parameters, it crashes in the ide - never in the runtime. This is on hundreds of test runs. Verified on 3 computers.

But not when you only run the snippet, right? So obviously some other part of the program is ruining the environment.

Edit: What I do when I have a mystic error like this, is to make a copy of the whole project, then deleting large portions of the program until the problem disappears.

Looks like that's my next step since I can't get the external debugger working...

Thanks for the advice.
-j

I still have no clue why you want to use the external debugger and why you're unable to select "standalone debugger" and press F5... What you get then IS the "external" or "standalone" debugger.

As a third option, just to prove the IDE is totally unrelated to this, you could try this:
1. Check "create temporary executable in source directory"
2. Enable the debugger and run from the IDE. Quit.
3. You now have an exe file in the source directory which is your program compiled with the debugger. The program can be ran directly from windows explorer with a double click. Since it was compiled with debugger, but it's not ran from the IDE nor with the standalone debugger, it will use a console debugger. You don't need to use the console debugger, just run the program to verify that it still crashes, even though you didn't run it from the IDE.

Edit: I need a clarification. When you disable the debugger and run it from the IDE, does it still crash? Or only with the debugger enabled.

[jassing]

I still have no clue why you want to use the external debugger and why you're unable to select "standalone debugger" and press F5... What you get then IS the "external" or "standalone" debugger.

I was trying not to hijack the thread...

When I build an exe and select "use external debugger" and then go to a command prompt and call the debugger and pass it my exe the debugger crashes. I can use it fine when run thru the ide.

I'm thinking I should make a video for this as it seems no one is understanding the problem....


Going with your "run the temp file" -- it errors -- if I compile to exe it doesn't. Not sure what this gets us.


when the debugger is disabled, it does not crash.

[Trond]

Going with your "run the temp file" -- it errors -- if I compile to exe it doesn't. Not sure what this gets us.

It proves that the problem is not the IDE. So using the standalone debugger wouldn't affect it.

when the debugger is disabled, it does not crash.

And this proves the same. So it's an issue of debugger/not debugger, and not an issue of IDE/not IDE. So using the standalone debugger will not help.

When I build an exe and select "use external debugger"

When you build an exe from the IDE, there is no debugger, ever, no matter what you select. Else you would constantly ship debug builds accidentally. To use the standalone debugger, select that, and press F5. But as I keep telling you, using the standalone debugger will not help you. Only one of two things can happen:
1. The program doesn't crash. That doesn't help you with finding the bug that is there somewhere.
2. The program crashes. That didn't help either.