December 06, 2015 Re: Visual D 0.3.43 beta1 available | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote: > > Now updated to a new beta: > > https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2 Hello! A small issue I noticed: If I create a configuration for x64, visual studio doesn't know that this means version(Win64) is true and version(Win32) is false, as seen here: http://imgur.com/Gui9rYz I verified that a pointer (using .sizeof) is 8 bytes with x64 configuration and 4 bytes with x86 configuration, so it's just the editor that doesn't know. |
December 07, 2015 Re: Visual D 0.3.43 beta1 available | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew LaChance | On 06.12.2015 01:16, Andrew LaChance wrote: > On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote: >> >> Now updated to a new beta: >> >> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2 >> > > Hello! A small issue I noticed: If I create a configuration for x64, > visual studio doesn't know that this means version(Win64) is true and > version(Win32) is false, as seen here: > > http://imgur.com/Gui9rYz > > I verified that a pointer (using .sizeof) is 8 bytes with x64 > configuration and 4 bytes with x86 configuration, so it's just the > editor that doesn't know. Thanks for reporting. You can also file issues at https://issues.dlang.org/enter_bug.cgi?product=D It seems that this happens for files that are not part of a project. It can be ambiguous what versions have to be defined for the source file, but Win64 should be taken from the selected platform. I remember having trouble detecting this setting for "compile and run", too. |
December 07, 2015 Re: Visual D 0.3.43 beta1 available | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew LaChance |
On 05.12.2015 21:50, Andrew LaChance wrote:
> On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote:
>>
>>
>> On 01.11.2015 11:29, Rainer Schuetze wrote:
>>> Hi,
>>>
>>> I just uploaded a beta for the next release of Visual D.
>>>
>>> You can find the list of changes and the installer here:
>>>
>>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
>>>
>>>
>>>
>>> Rainer
>>
>> Now updated to a new beta:
>>
>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2
>>
>
> Thank you for the update! It fixed my link issues.
>
> I have found a very strange issue with I *think* visual D. I have
> condensed into a very small repro here: http://1drv.ms/1Oai14L (entire
> solution). If I build and run on x86 build config, everything is fine.
> But on x64, debugging (with Debug x64 config) will cause an exception
> somewhere on this line:
>
> writeln(AnotherColor.Red.stringof); // AnotherColor is an enum
>
> But if I were to run the exe from the command line it is fine. Release
> version is fine too. Also, it is fine if I put a breakpoint on the
> first line in main.d and then step over each line. But hitting continue
> will throw an exception. I'm not exactly sure where the exception comes
> from:
>
> DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x32 bytes D
>
> DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes D
>
> DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv()
> + 0x3c bytes D
>
> DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes D
> DPlayground.exe!_d_run_main() + 0x421 bytes D
> DPlayground.exe!__entrypoint.main( int argc, char** argv ) + 0x22
> bytes D
>> DPlayground.exe!invoke_main() Line 75 D
> DPlayground.exe!__scrt_common_main_seh() Line 264 + 0x5 bytes D
> DPlayground.exe!__scrt_common_main() Line 309 D
> DPlayground.exe!mainCRTStartup() Line 17 D
>
> Have you seen anything like this before?
I can reproduce the problem here. This is caused by the breakpoint modifying the code at a wrong instruction address, which leads to a bad stack cleanup.
As this happens for all debug engines, it is very likely due to bad debug information emitted by dmd.
|
December 10, 2015 Re: Visual D 0.3.43 beta1 available | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | On Monday, 7 December 2015 at 08:27:54 UTC, Rainer Schuetze wrote:
>
>
> On 05.12.2015 21:50, Andrew LaChance wrote:
>> [...]
>
> I can reproduce the problem here. This is caused by the breakpoint modifying the code at a wrong instruction address, which leads to a bad stack cleanup.
>
> As this happens for all debug engines, it is very likely due to bad debug information emitted by dmd.
Oh wow, that sounds nasty! Is there a bug in dmd for this?
|
December 11, 2015 Re: Visual D 0.3.43 beta1 available | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew LaChance | On 10.12.2015 05:56, Andrew LaChance wrote: > On Monday, 7 December 2015 at 08:27:54 UTC, Rainer Schuetze wrote: >> >> >> On 05.12.2015 21:50, Andrew LaChance wrote: >>> [...] >> >> I can reproduce the problem here. This is caused by the breakpoint >> modifying the code at a wrong instruction address, which leads to a >> bad stack cleanup. >> >> As this happens for all debug engines, it is very likely due to bad >> debug information emitted by dmd. > > Oh wow, that sounds nasty! Is there a bug in dmd for this? I have added a report here: https://issues.dlang.org/show_bug.cgi?id=15432 |
Copyright © 1999-2021 by the D Language Foundation