Visual D 1.2.0-rc1 available

[Rainer Schuetze]

On 12/01/2022 05:41, Complexity wrote:
> On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze wrote:
>>
>>
>> On 19/12/2021 17:53, Complexity wrote:
>>> Visual D is crashing Visual Studio 2022 after doing a fresh install 
>>> of both. This seems to be happening when debugging and adding 
>>> breakpoints. Did not happen with 2019 so it's either the VisualD 
>>> release(I think I was using the same) or due to 2022.
>>>
>>> I think simply trying to debug a program will give you the crash.
>>
>> Cannot reproduce here, e.g. on the dmdserver executable. Do you find a 
>> crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
> 
> No, it doens't produce it, although I had a few crash dumps from 
> 12-30-21 involving the dmd server so maybe it was them.

I forgot that writing the dumps is not enabled by default. Here's a 
description of the necessary registry entries to enable it:

https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

The next Visual D installer will enable it for dmdserver.exe, but not 
for other applications.

> 
> c:\Users\name\AppData\Local\CrashDumps BTW
> 
> It does it both with x64 and x86 although I tried to run it with buggy 
> code(trying to modify some code and had a bug(array accessor) and it 
> crashed in to the debugger but at the entrypoint code with no real 
> information about what happened(but since it was a minor change and an 
> array index error(length instead of length-1 basically) it was obvious 
> where the bug was. So without BP's it does go in to the debugger, more 
> or less but with BP's it crashes VS entirely.
> 
> This is 100% due to upgrading to Visual Studio 2022. I tried another 
> project and I get "cannot launch debbugger on ... hr 89710016".

Are you using the visualdproj format projects or the integration with 
VC++ projects. If the former, don't use the legacy "Mago" debug engine, 
it is not supported in a 64-bit environment like VS 2022 (though 
unfortunately still the default for new projects). Both "Visual Studio" 
debug engines integrate the Mago debugger extension.

> I also get the error
> Severity    Code    Description    Project    File    Line    
> Suppression State
> Error        Error: file `"Plotter.py"` cannot be found or not in a path 
> specified with `-J`
> C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by 
> `-J`):        C:\Projects\XXX\XXX.d    125

This seems unrelated and is likely some option -J missing within the 
language server.

> 
> Which never occurred before upgrading and seems to not stop the program 
> from working(I have the -J and since it's compiling it is finding the 
> file so this seems to be another bug, maybe related).
> 
> Clearly something is off. I'm pretty sure just a few days ago I was able 
> to run that same project(a different one and a new project I created 
> recently under the new VS) so the issue with launching the debugger 
> maybe because it crashed when I was trying to debug the first project 
> and now it can't launch.
> 
> I'll reboot and try again later. (The reason I say it must have worked 
> is because I had a BP set in the project and don't remember it not 
> working at all)
> 
> So maybe it is an issue with debug information in projects created in 
> previous versions of VS that are not translating debug information 
> correctly to newer projects?
> 
> If you tried it on a fresh project maybe open up an old one and see. 
> (although I do think that the project I used was old but I heavily 
> modified it)
> 
> Almost surely some type of memory access issue given the nature of the 
> crash.

Cannot reproduce with some sample projects, e.g. the Visual D istself or 
the D compiler. I suspect it depends on the variables being shown in the 
Locals/Auto Window.

> 
> What happens when I place a breakpoint then run the program it does show 
> the code and the yellow arrow on top of the red BP disk and then it 
> shows the crash dialog about "The instruction at ... references memory 
> at .... The memory could not be written.".
> 
> If I try to debug it then it opens up a new VS with the devenv.exe but 
> nothing really is going on and then if I click start debugging it will 
> run VS. If I open up the project then it says an exception is thrown 
> with "Exception thrown at .... (comctl32.dll) in devenv.exe: 
> 0xC00000005: Access violation writing location ....
> 
> It also says comctl32.pdb not loaded but not sure if that has anything 
> to do with it.
> 
> Does any of this make any sense? Maybe the comctl32.dll is corrupted or 
> versioned wrong or something?

Hard to say without a full stack trace or dump. Missing symbols for the 
last release, please retry with the next one.