www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Visual D no bp's on x64

reply Mike B Johnson <Mikey Ikes.com> writes:
in the last 20mins I did the following

1. Create a new DMD/LDC project

2. Added the code

import std.stdio;
import core.sys.windows.windows;
import std.array, std.conv;

int main(string[] argv)
{

	wchar* pCmd = cast(wchar*)to!wstring(argv.join(" ")).ptr;

	
     STARTUPINFO si;
     //ZeroMemory( &si, sizeof(si) );
     si.cb = si.sizeof;
     PROCESS_INFORMATION pi;
     //ZeroMemory(&pi, sizeof(pi));

     // Start the child process.
     BOOL result = CreateProcess
     (
         NULL, // No module name (use command line)
         pCmd, // Command line
         NULL, // Process handle not inheritable
         NULL, // Thread handle not inheritable
         FALSE, // Set bInheritHandles to FALSE
         DETACHED_PROCESS, // Detach process
         NULL, // Use parent's environment block
         NULL, // Use parent's starting directory
         &si, // Pointer to STARTUPINFO structure
         &pi // Pointer to PROCESS_INFORMATION structure (returned)
     );
     if (result) return 0;

     wchar[2048] msg;
     FormatMessage
     (
         FORMAT_MESSAGE_FROM_SYSTEM,
         null,
         GetLastError(),
         cast(uint)MAKELANGID(LANG_NEUTRAL, SUBLANG_SYS_DEFAULT),
         msg.ptr, cast(uint)2048,
         null
     );
	
     writeln(msg[0..lstrlen(msg.ptr)]);

     return -1;
}

3. Modified the command args in the options. Added cmd /c echo 
hello

4. Then went to debug it by putting a bp on the first line so I 
could check and ran it. Guess what? The program opened and 
closed. I've ran in to this problem before.

5. I added a bunch of bp's thinking it was just a problem with 
the first one(as that is how I get around it before).

6. Ran the program. Same thing. Ran the program. Same thing. I 
noticed that the bp's were turning white the split second the 
program was active.

hmmm... I then noticed the program was being built for x64.

7. I then changed it to x86 and voilà!

So, there is some issue with x64 and visual d's debugging in 
visual studio. That is the only file in the project. If it works 
on your system, keep trying until it doesn't!
Jun 18 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2017 16:17, Mike B Johnson wrote:

 So, there is some issue with x64 and visual d's debugging in visual 
 studio. That is the only file in the project. If it works on your 
 system, keep trying until it doesn't!


As you expected, its not simple to reproduce. I have not managed to do so.

Could you specify a few more details:

- Visual D version?
- VS version?
- Which Configuration selected?
- dmd version?
- ldc version (in case you switched to "LDC Debug")?
- selected debug engine?

Slightly unrelated, but one thing that often bothers me: if you open the 
project configuration dialog, VS doesn't always show the current 
configuration (but the last edited one), so you edit options that don't 
seem to have any effect.
Jun 18 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2017 16:50, Rainer Schuetze wrote:

 
 
 On 18.06.2017 16:17, Mike B Johnson wrote:

 So, there is some issue with x64 and visual d's debugging in visual 
 studio. That is the only file in the project. If it works on your 
 system, keep trying until it doesn't!


 
 As you expected, its not simple to reproduce. I have not managed to do so.
 
 Could you specify a few more details:
 
 - Visual D version?
 - VS version?
 - Which Configuration selected?
 - dmd version?
 - ldc version (in case you switched to "LDC Debug")?
 - selected debug engine?
 
 Slightly unrelated, but one thing that often bothers me: if you open the 
 project configuration dialog, VS doesn't always show the current 
 configuration (but the last edited one), so you edit options that don't 
 seem to have any effect.


I could produce an issue when starting the mago debugger for the first 
time after firing up VS2015: it showed an error, though, instead of not 
doing anything at all. Maybe it's a different effect of the same 
problem. I have added a work around that fixes it for me: 
https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts

BTW: the output window should show whether symbols for your application 
have been loaded. If not, you get the behavior that you reported.
Jun 18 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 18 June 2017 at 17:43:20 UTC, Rainer Schuetze wrote:

 On 18.06.2017 16:50, Rainer Schuetze wrote:

 
 
 On 18.06.2017 16:17, Mike B Johnson wrote:

 So, there is some issue with x64 and visual d's debugging in 
 visual studio. That is the only file in the project. If it 
 works on your system, keep trying until it doesn't!


 
 As you expected, its not simple to reproduce. I have not 
 managed to do so.
 
 Could you specify a few more details:
 
 - Visual D version?
 - VS version?
 - Which Configuration selected?
 - dmd version?
 - ldc version (in case you switched to "LDC Debug")?
 - selected debug engine?
 
 Slightly unrelated, but one thing that often bothers me: if 
 you open the project configuration dialog, VS doesn't always 
 show the current configuration (but the last edited one), so 
 you edit options that don't seem to have any effect.


 I could produce an issue when starting the mago debugger for 
 the first time after firing up VS2015: it showed an error, 
 though, instead of not doing anything at all. Maybe it's a 
 different effect of the same problem. I have added a work 
 around that fixes it for me: 
 https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts

 BTW: the output window should show whether symbols for your 
 application have been loaded. If not, you get the behavior that 
 you reported.


Didn't work ;/

All I get on the output wndow is

"
C:\Windows\System32\dbghelp.dll unloaded.
The thread 0x1ea4 has exited with code -1 (0xffffffff).
The thread 0x1390 has exited with code -1 (0xffffffff).
The thread 0x1ac has exited with code -1 (0xffffffff).
The program '[492] Async.exe' has exited with code -1 
(0xffffffff).
"
Jun 18 2017
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2017 20:25, Mike B Johnson wrote:

 
 Didn't work ;/
 
 All I get on the output wndow is
 
 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 (0xffffffff).
 "


It seems the debug engine is only attached to the process when it starts 
terminating. Nothing cut off at the top? Strange.

Please try switching to the Visual Studio debug engine on the project 
debugger configuration page. This still uses mago as the D expression 
evaluator, but has all the other features of the VS debugger. It's 
actually the new and preferred way to run the debugger since the last 
Visual D release, especially with mixed languages.
Jun 18 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 
 Didn't work ;/
 
 All I get on the output wndow is
 
 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 
 (0xffffffff).
 "


 It seems the debug engine is only attached to the process when 
 it starts terminating. Nothing cut off at the top? Strange.

 Please try switching to the Visual Studio debug engine on the 
 project debugger configuration page. This still uses mago as 
 the D expression evaluator, but has all the other features of 
 the VS debugger. It's actually the new and preferred way to run 
 the debugger since the last Visual D release, especially with 
 mixed languages.


Doesn't work. Nothing is cut off. the x86 version is loading a 
bunch of symbols so maybe it is just a path issue? Is so then it 
should print a proper error message for it. I'll try to play 
around with the paths and see.
Jun 19 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 20.06.2017 02:05, Mike B Johnson wrote:

 On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 Didn't work ;/

 All I get on the output wndow is

 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 (0xffffffff).
 "


 It seems the debug engine is only attached to the process when it 
 starts terminating. Nothing cut off at the top? Strange.

 Please try switching to the Visual Studio debug engine on the project 
 debugger configuration page. This still uses mago as the D expression 
 evaluator, but has all the other features of the VS debugger. It's 
 actually the new and preferred way to run the debugger since the last 
 Visual D release, especially with mixed languages.


 
 Doesn't work. Nothing is cut off. the x86 version is loading a bunch of 
 symbols so maybe it is just a path issue? Is so then it should print a 
 proper error message for it. I'll try to play around with the paths and 
 see.


Did you have success debugging your x64 builds? I've committed a small 
change to the mago debugger, maybe it helps. There is a new installer 
here: https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1

If that still fails: Does debugging a C++ application work? If it does, 
you could try exchanging the debug executable in the C++ project with 
the D executable and see if that can be debugged.
Jul 11 2017
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2017 20:25, Mike B Johnson wrote:

 I could produce an issue when starting the mago debugger for the first 
 time after firing up VS2015: it showed an error, though, instead of 
 not doing anything at all. Maybe it's a different effect of the same 
 problem. I have added a work around that fixes it for me: 
 https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e2
e7hxgty4b/artifacts 


 BTW: the output window should show whether symbols for your 
 application have been loaded. If not, you get the behavior that you 
 reported.


 
 Didn't work ;/
 
 All I get on the output wndow is
 
 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 (0xffffffff).
 "


After installing VS2017 on a fresh Win10 install I could reproduce this 
issue: the mago debug engine failed to load the symbols when only VS2017 
is installed, because the COM-CLSID to load msdia140.dll changed. 
Switching to the VS debug engine worked, though.

Should be fixed in the next release.
Jul 22 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 [...]


 
 Didn't work ;/
 
 All I get on the output wndow is
 
 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 
 (0xffffffff).
 "


 After installing VS2017 on a fresh Win10 install I could 
 reproduce this issue: the mago debug engine failed to load the 
 symbols when only VS2017 is installed, because the COM-CLSID to 
 load msdia140.dll changed. Switching to the VS debug engine 
 worked, though.

 Should be fixed in the next release.


I installed a fresh VS2017 and the latest beta visual D and same 
issues. As of today, was this suppose to be fixed?
Jul 31 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.07.2017 19:51, Johnson Jones wrote:

 On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 [...]


 Didn't work ;/

 All I get on the output wndow is

 "
 C:\Windows\System32\dbghelp.dll unloaded.
 The thread 0x1ea4 has exited with code -1 (0xffffffff).
 The thread 0x1390 has exited with code -1 (0xffffffff).
 The thread 0x1ac has exited with code -1 (0xffffffff).
 The program '[492] Async.exe' has exited with code -1 (0xffffffff).
 "


 After installing VS2017 on a fresh Win10 install I could reproduce 
 this issue: the mago debug engine failed to load the symbols when only 
 VS2017 is installed, because the COM-CLSID to load msdia140.dll 
 changed. Switching to the VS debug engine worked, though.

 Should be fixed in the next release.


 
 I installed a fresh VS2017 and the latest beta visual D and same issues. 
 As of today, was this suppose to be fixed?


It hasn't been released until now: 
https://github.com/dlang/visuald/releases/tag/v0.45.0
Aug 03 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze wrote:

 On 31.07.2017 19:51, Johnson Jones wrote:

 On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze 
 wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 [...]


 After installing VS2017 on a fresh Win10 install I could 
 reproduce this issue: the mago debug engine failed to load 
 the symbols when only VS2017 is installed, because the 
 COM-CLSID to load msdia140.dll changed. Switching to the VS 
 debug engine worked, though.

 Should be fixed in the next release.


 
 I installed a fresh VS2017 and the latest beta visual D and 
 same issues. As of today, was this suppose to be fixed?


 It hasn't been released until now: 
 https://github.com/dlang/visuald/releases/tag/v0.45.0


Thanks! Seems to be working.
Aug 03 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Thursday, 3 August 2017 at 20:22:56 UTC, Johnson Jones wrote:

 On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze 
 wrote:

 On 31.07.2017 19:51, Johnson Jones wrote:

 On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze 
 wrote:

 On 18.06.2017 20:25, Mike B Johnson wrote:

 [...]


 After installing VS2017 on a fresh Win10 install I could 
 reproduce this issue: the mago debug engine failed to load 
 the symbols when only VS2017 is installed, because the 
 COM-CLSID to load msdia140.dll changed. Switching to the VS 
 debug engine worked, though.

 Should be fixed in the next release.


 
 I installed a fresh VS2017 and the latest beta visual D and 
 same issues. As of today, was this suppose to be fixed?


 It hasn't been released until now: 
 https://github.com/dlang/visuald/releases/tag/v0.45.0


 Thanks! Seems to be working.


well, in x86 I still get a few BP's that won't be hit every once 
in a while(well, happened for the first time since I've used the 
new release).


The code looks like

while(i < data.length && data[i] != '>' && data[i] != '"' && 
data[i..i+token2.length] != token2) i++;
if (data[i] == '>') { continue; }

I put a BP on the if and when ran it says it won't be hit. I have 
a BP right above it and below it and it works fine.

says "The BP will not currently be hit. No symbols have been 
loaded for this document.". I do not know why symbols really 
matter for BP's?


If I change the if statement to

			if (data[i] == '>')
			{
				continue;
			}

it works ;/
Aug 05 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Sunday, 6 August 2017 at 03:12:22 UTC, FoxyBrown wrote:

 On Thursday, 3 August 2017 at 20:22:56 UTC, Johnson Jones wrote:

 On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze 
 wrote:

 [...]


 Thanks! Seems to be working.


 well, in x86 I still get a few BP's that won't be hit every 
 once in a while(well, happened for the first time since I've 
 used the new release).


 The code looks like

 while(i < data.length && data[i] != '>' && data[i] != '"' && 
 data[i..i+token2.length] != token2) i++;
 if (data[i] == '>') { continue; }

 I put a BP on the if and when ran it says it won't be hit. I 
 have a BP right above it and below it and it works fine.

 says "The BP will not currently be hit. No symbols have been 
 loaded for this document.". I do not know why symbols really 
 matter for BP's?


 If I change the if statement to

 			if (data[i] == '>')
 			{
 				continue;
 			}

 it works ;/


Oops, it "works". The BP icon is no longer a hollow read disk but 
it is simply not hit ;/

I know all this doesn't help much but it all seems to be related 
to the previous bugs.
Aug 05 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 06.08.2017 05:21, FoxyBrown wrote:

 On Sunday, 6 August 2017 at 03:12:22 UTC, FoxyBrown wrote:

 On Thursday, 3 August 2017 at 20:22:56 UTC, Johnson Jones wrote:

 On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze wrote:

 [...]


 Thanks! Seems to be working.


 well, in x86 I still get a few BP's that won't be hit every once in a 
 while(well, happened for the first time since I've used the new release).


 The code looks like

 while(i < data.length && data[i] != '>' && data[i] != '"' && 
 data[i..i+token2.length] != token2) i++;
 if (data[i] == '>') { continue; }

 I put a BP on the if and when ran it says it won't be hit. I have a BP 
 right above it and below it and it works fine.

 says "The BP will not currently be hit. No symbols have been loaded 
 for this document.". I do not know why symbols really matter for BP's?


 If I change the if statement to

             if (data[i] == '>')
             {
                 continue;
             }

 it works ;/


 
 Oops, it "works". The BP icon is no longer a hollow read disk but it is 
 simply not hit ;/
 
 I know all this doesn't help much but it all seems to be related to the 
 previous bugs.


It would be good if you could post the full function, even better a 
complete compilable file exposing the problem.

I suspect dmd just doesn't produce proper debug information. For example 
"continue" is often optimized away due to some branches even removed in 
debug code.
Aug 06 2017