[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #34 from github-bugzi...@puremagic.com --- Commits pushed to newCTFE at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a96a3f976204011f083b9af2353e839fcbd8dc72 fix Issue 16699 - [REG 2.070] stack corruption with scope(exit) https://github.com/dlang/dmd/commit/7776ed4d7e33cd9edae02d15120a9a6c43239a80 Merge pull request #6261 from WalterBright/fix16699 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #33 from github-bugzi...@puremagic.com --- Commits pushed to scope at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a96a3f976204011f083b9af2353e839fcbd8dc72 fix Issue 16699 - [REG 2.070] stack corruption with scope(exit) https://github.com/dlang/dmd/commit/7776ed4d7e33cd9edae02d15120a9a6c43239a80 Merge pull request #6261 from WalterBright/fix16699 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #32 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a96a3f976204011f083b9af2353e839fcbd8dc72 fix Issue 16699 - [REG 2.070] stack corruption with scope(exit) https://github.com/dlang/dmd/commit/7776ed4d7e33cd9edae02d15120a9a6c43239a80 Merge pull request #6261 from WalterBright/fix16699 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #31 from anonymous4 --- The obvious solution is to create a different merge PR that will just merge and nothing more. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #30 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #29) > ok, i'm giving up. if inability to merge master is simply dismissed with > "this is not a typical occurence" excuse, i have nothing else to say. For instance: https://github.com/dlang/dmd/pull/5792 This is typical. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #29 from Ketmar Dark --- ok, i'm giving up. if inability to merge master is simply dismissed with "this is not a typical occurence" excuse, i have nothing else to say. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #28 from Steven Schveighoffer --- ketmar, since 11 days ago, merge from stable to master has been created. However, there is some issue (which I admittedly have no understanding of), and when that issue is resolved, this will be in master. I still think the process as-is is what we should have. This is not a typical occurrence, usually stable->master PRs are merged in a day. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #27 from Ketmar Dark --- oops. you provided PR that doesn't belong to this thread, and i didn't checked it properly. still, my point stands. ;-) --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #26 from Ketmar Dark --- and now we have this "fix" in *stable*! do you still think that "nothing should be changed"? for me, this issue clearly indicates that something is *very* broken in the current scheme. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #25 from Steven Schveighoffer --- Looks like there is a snag: https://github.com/dlang/dmd/pull/6287 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #24 from Ketmar Dark --- so, time is passing on. nothing was merged to master. versions diverges more and more. definitely, the system works just fine. i can't see nothing that should be changed in the way things works now. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #23 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #22) > (In reply to Steven Schveighoffer from comment #21) > > People file bug reports for released compilers not realizing it's already > > fixed in master. > > how can it be? if there was bug, and it was fixed -- we have closed > bugreport. It's simple. Person downloads latest compiler release, tries something, doesn't work. They file a bug. People don't regularly use the master release of the compiler. Yes, we have a very very good system for making sure that the master compiler is generally usable, but it means building from scratch. Most people just want to get work done, and are not interested in compiler/runtime development. In any case, I think the system works just fine as is. Just close a bug when its commit is in master or stable, and we should be fine. If we had a "FIXED IN STABLE" bugzilla resolution, that was then moved to just "FIXED" automatically when the merge occurred, then perhaps this would be helpful. But I don't think it's necessary. The amount of time between a bug being fixed in stable and then moving to master is quite small. Seems like a lot of effort for such little gain. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #22 from Ketmar Dark --- (In reply to Steven Schveighoffer from comment #21) > Says the guy who thinks creating a github account is an undue burden ;) let's be fair here: i believe that increasing gh userbase in unethical, as gh employees are publicly racist/sjw (and so gh as a whole). there are other similar reasons, but it is OT. ;-) similarly, i will depart from D community and D itself immediately if D will adopt any "code of conduct". > In any case, the current workflow is not going to change, it works actually > quite well the way it is, and I would be very against changing it. T_T > People file bug reports for released compilers not realizing it's already > fixed in master. how can it be? if there was bug, and it was fixed -- we have closed bugreport. it doesn't matter in what branch it was. but people who want to develop something for D are going to clone master and then have bugs that are closed and marked as fixed actually unfixed. that is... i don't even have a word for it. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #21 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #19) > sure, this may add some burden on devs, but i believe that it is better and > helthier way to do developement work. Says the guy who thinks creating a github account is an undue burden ;) In any case, the current workflow is not going to change, it works actually quite well the way it is, and I would be very against changing it. People file bug reports for released compilers not realizing it's already fixed in master. They file duplicates all the time. We can't avoid all situations of having someone miss that a bug is already fixed. What we can do, is avoid the situation that a bug report is advertising a fix is needed, when one is already implemented and accepted. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #20 from anonymous4 --- (In reply to hsteoh from comment #18) > @Steven: I see your point about preventing redundant fixes. But it's still > confusing that a bug has been resolved as fixed, yet the bug persists in > master. :-) dlang uses simple bugfix lifetime: it's resolved (not closed) as soon as the fix is commited. Usually the bug is closed when QA confirms the fix in a released product, but since we have no QA, bugs are never closed. Also in order to know, where to verify a fix, the numeric product version should be specified, not a branch. If you want to test new features, use the master branch, if you want stable version, use stable branch. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #19 from Ketmar Dark --- actually, i believe that no merges from stable to master should be done at all. if hotfix is applicable to both branches, it should go to both branches, first in master, and then, possibly with another PR, in stable. not the other way around. if autotester is the blocker, then something should be done with autotester. but in no way master aka "dev" should be behind stable in terms of bugfixes. all the new developement is done on master, so master should have all bugs fixed first, so people won't spend time chasing the bug that may be fixed in stable, but not merged to master yet. actually, i think that PRs against stable should be rejected if there is no equivalent PR against master, or link to already existing PR that fixed the bug. sure, this may add some burden on devs, but i believe that it is better and helthier way to do developement work. for now it is unclear which branch has bug fixed, for example. it is marked as fixed in bugzilla? ok, i'll go with my dev work the... oh, wait! it is not fixed in master! so i have to rebase my work on stab... oh, wait! we aren't doing dev against stable! ok, i'll cherry-pick it myse... oh, wait, merge arrived! ah, fsck all that mess, i already lost the motivation. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #18 from hst...@quickfur.ath.cx --- @Steven: I see your point about preventing redundant fixes. But it's still confusing that a bug has been resolved as fixed, yet the bug persists in master. :-) Is there a way for bugzilla to indicate which branch(es) a bug has been fixed in? Debian's Bug Tracking System, for example, in the recent years got a new feature where it keeps track of all the releases (experimental/unstable/testing/stable) that a bug has been fixed in, so that you can tell at a glance whether or not the fix is in the release you're interested in. Debian's BTS also tracks the package version number that a fix was first implemented in, so you can check whether you have the fix by looking at the version string, even if you're not using the official .deb repositories. Although, this is probably not applicable in our case. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #17 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #15) > the whole process is broken: under no circumstances any hotfix that is > applicable both to master and to stable can land in stable first. Oh, I may have misread your point. It has to go into stable first, because you can't merge master into stable. Only the other way around. What I thought you were asking is for stable to be merged into master every time a fix is pulled. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #16 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #15) > the whole process is broken: under no circumstances any hotfix that is > applicable both to master and to stable can land in stable first. It's advantageous to do it "all at once" instead of one at a time. Keep in mind that the auto tester needs to test all these. I'd rather have it test the "whole thing" at once one time rather than test each hotfix as it's produced when it's already been tested on stable. In addition, the PRs for merging stable to master are not always straightforward. Less work if you do it all at once. (In reply to hsteoh from comment #10) > Is it customary to close bugs once they are fixed in stable, even though the > fix has not yet been merged to git HEAD? Yes, once a commit happens, the issue should be closed, as long as it's going to go into master. Imagine if someone notices this is not fixed, and creates a PR for master without realizing it's already fixed :) Not that I've ever done that... Note that anyone can create a PR to merge stable to master. It's just another PR. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #15 from Ketmar Dark --- the whole process is broken: under no circumstances any hotfix that is applicable both to master and to stable can land in stable first. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #14 from hst...@quickfur.ath.cx --- Eventually all fixes in stable get merged to master. It's just that in the interim, I'm wondering whether bugs that still exist in master should be kept open until the merge happens, or as soon as stable gets the fix. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 Ketmar Dark changed: What|Removed |Added See Also|https://issues.dlang.org/sh | |ow_bug.cgi?id=16102 | --- Comment #13 from Ketmar Dark --- any such fix should go to master *too*, in the same time. it is... strange to have a developement version with bugs that was fixed in release version, considering that master is what people is using to develop/test new features. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #12 from ag0ae...@gmail.com --- (In reply to hsteoh from comment #10) > Is it customary to close bugs once they are fixed in stable, even though the > fix has not yet been merged to git HEAD? I don't see why master would be the branch to look at. If anything, I'd say stable is more fitting, because the fix being in stable means it gets into the next point release, whereas if it's in master it only gets into the next major release. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #10 from hst...@quickfur.ath.cx --- Is it customary to close bugs once they are fixed in stable, even though the fix has not yet been merged to git HEAD? --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #11 from hst...@quickfur.ath.cx --- 'cos this is not yet working in git HEAD. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #9 from ag0ae...@gmail.com --- *** Issue 16698 has been marked as a duplicate of this issue. *** --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a96a3f976204011f083b9af2353e839fcbd8dc72 fix Issue 16699 - [REG 2.070] stack corruption with scope(exit) https://github.com/dlang/dmd/commit/7776ed4d7e33cd9edae02d15120a9a6c43239a80 Merge pull request #6261 from WalterBright/fix16699 fix Issue 16699 - [REG 2.070] stack corruption with scope(exit) --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #7 from Walter Bright --- It's not even a regression. It's always been there, lurking. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All OS|Linux |All --- Comment #6 from Walter Bright --- Although this showed up on Linux, it potentially affects all targets. It had nothing to do with exception handling, other than that perturbed things enough to expose it. Similarly, -O had nothing to do with it. https://github.com/dlang/dmd/pull/6261 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #5 from hst...@quickfur.ath.cx --- Unfortunately, the -O trick doesn't work with issue 16698. So it's not a reliable workaround for this bug. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #4 from hst...@quickfur.ath.cx --- Yet another data point: compiling with -O makes the problem go away(!). Somehow, I guess the optimizer must be working at a higher level of abstraction, and was able to deduce the correct semantics and enregister the static array, thus avoiding this particular codegen bug. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #3 from hst...@quickfur.ath.cx --- P.S., in the bad code case, %rax contains the address of a local variable used to store the static array, but %rdx appears to contain the correct return value. Did the codegen somehow fail to leave the return value in the right register? --- 004274e8 : 4274e8: 55 push %rbp 4274e9: 48 8b ecmov%rsp,%rbp 4274ec: 48 83 ec 20 sub$0x20,%rsp 4274f0: 48 8d 45 e8 lea-0x18(%rbp),%rax // %rax := &(%rbp - 0x18) 4274f4: 31 c9 xor%ecx,%ecx 4274f6: 48 89 08mov%rcx,(%rax) // local var (*%eax) := 0 4274f9: 48 89 4d e8 mov%rcx,-0x18(%rbp) // local var (%rbp - 0x18) := 0 (redundant store?) 4274fd: 48 8b 55 e8 mov-0x18(%rbp),%rdx // %rdx := *(%rbp - 0x18) 427501: c7 45 f0 01 00 00 00movl $0x1,-0x10(%rbp) 427508: eb 0d jmp427517 42750a: eb 0b jmp427517 // dead code? 42750c: 48 89 45 f8 mov%rax,-0x8(%rbp) 427510: c7 45 f0 00 00 00 00movl $0x0,-0x10(%rbp) // dead code? 427517: 83 7d f0 00 cmpl $0x0,-0x10(%rbp) 42751b: 75 09 jne427526 // if (*(%rbp - 0x10) != 0) 42751d: 48 8b 7d f8 mov-0x8(%rbp),%rdi 427521: e8 7a fe ff ff callq 4273a0 <_Unwind_Resume@plt> 427526: 83 7d f0 01 cmpl $0x1,-0x10(%rbp) // if (*(%rbp - 0x10) == 1) return; 42752a: 74 06 je 427532 42752c: 83 7d f0 02 cmpl $0x2,-0x10(%rbp) 427530: c9 leaveq 427531: c3 retq 427532: c9 leaveq 427533: c3 retq --- --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 --- Comment #2 from hst...@quickfur.ath.cx --- Looking at the assembly, it seems like a codegen bug. The static array is actually correctly initialized with the return value, but when scope(exit){} is uncommented, the return value (%eax) is never set, thus it's left as a garbage value. When scope(exit){} is commented out, the return value is (correctly) loaded into %eax and the caller is able to receive the right value. --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 anonymous4 changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16102 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 Marc Schütz changed: What|Removed |Added CC||schue...@gmx.net --- Comment #1 from Marc Schütz --- Digger finds this as the culprit: commit 5498a84606008426ff1a9f6b2a493e083715e74c Author: Martin Nowak Date: Sat Jan 2 18:44:59 2016 +0100 dmd: Merge pull request #5324 from WalterBright/enable-dwarfeh https://github.com/D-Programming-Language/dmd/pull/5324 Dwarf EH: enable it There's also a reference to another bug in this PR: https://issues.dlang.org/show_bug.cgi?id=15625 --
[Issue 16699] [REG 2.070] stack corruption with scope(exit)
https://issues.dlang.org/show_bug.cgi?id=16699 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --