[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 --- Comment #7 from Vladimir Panteleev --- (In reply to Jacob Carlborg from comment #6) > A file descriptor to the executable also seems to be available in the > auxiliary vector on Linux [1]. This can be accessed with the function > `getauxval` or directly after the `envp` parameter in the C main function. I > see references to the auxiliary vector in *BSD systems as well. Might be > worth checking out. Interesting, though as far as I can see, that file descriptor is only available to interpreters, and is no longer there at the time that the interpreted program has begun execution. Otherwise, it would take up a file descriptor slot, and thus would be a very noticeable fourth addition to the standard stdin/stdout/stderr streams. So it doesn't look like we can use this unfortunately. --
[Issue 21658] Debugger is reading enums with EnumBaseType incorrectly
https://issues.dlang.org/show_bug.cgi?id=21658 alexanderheisterm...@gmail.com changed: What|Removed |Added Hardware|x86 |All --
[Issue 21658] Debugger is reading enums with EnumBaseType incorrectly
https://issues.dlang.org/show_bug.cgi?id=21658 alexanderheisterm...@gmail.com changed: What|Removed |Added Severity|enhancement |normal --
[Issue 21658] New: Debugger is reading enums with EnumBaseType incorrectly
https://issues.dlang.org/show_bug.cgi?id=21658
Issue ID: 21658
Summary: Debugger is reading enums with EnumBaseType
incorrectly
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: visuald
Assignee: nob...@puremagic.com
Reporter: alexanderheisterm...@gmail.com
Basic example:
enum X : ubyte { A, B, C }
void main()
{
X x = X.A;
}
it reads x as an ubyte type instead of a enum type
--
[Issue 21647] pragma(msg) should be able to print a void type
https://issues.dlang.org/show_bug.cgi?id=21647 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #12211 "fix Issue 21647 - pragma(msg) should be able to print a void type" was merged into master: - c867a41f72a6be4ba50a39d3739a3414d8fb8cb5 by Walter Bright: fix Issue 21647 - pragma(msg) should be able to print a void type https://github.com/dlang/dmd/pull/12211 --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #6 from Jacob Carlborg --- `thisExePath` uses `/proc/self/exe` on Linux, but it uses `readlink` to read out the path, instead of opening the actual file. `getprogname` is no better than `program_invocation_name`. They have more or less the same semantics. `getprogname` returns what was stored by `setprogname`. This is what the man pages say about `setprogname`: The setprogname() function sets the name of the program to be the last component of the progname argument. The best would probably be to copy the implementation of `thisExePath`, but change it to open the file and return a file descriptor. A file descriptor to the executable also seems to be available in the auxiliary vector on Linux [1]. This can be accessed with the function `getauxval` or directly after the `envp` parameter in the C main function. I see references to the auxiliary vector in *BSD systems as well. Might be worth checking out. BTW, there does not seem to be a reliable way to get the path to the current executable on OpenBSD. [1] http://articles.manugarg.com/aboutelfauxiliaryvectors.html [2] https://lwn.net/Articles/519085/ --
[Issue 21638] std.typecons.RefCounted!(T, RefCountedAutoInitialize.no) should still work when T.this() is annotated with `@disable`
https://issues.dlang.org/show_bug.cgi?id=21638 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7797 "std.typecons.RefCounted!(T, RefCountedAutoInitialize.no) should still work when T.this() is annotated with `@disable`" was merged into master: - 35035d4cfe239cdbf07b30015fbba143313d75e3 by Nathan Sashihara: Fix Issue 21638 - std.typecons.RefCounted!(T, RefCountedAutoInitialize.no) should still work when T.this() is annotated with `@disable` https://github.com/dlang/phobos/pull/7797 --
[Issue 21629] std.csv report one record on empty input
https://issues.dlang.org/show_bug.cgi?id=21629 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #7788 "Fixes #21629: std.csv report one record on empty input" was merged into master: - fac12450fbf6b707976cc84694e94c3c363bc75f by Robert burner Schadek: Fixes #21629 * nicer assert * fixing the cov linter hints * forgot some dead code https://github.com/dlang/phobos/pull/7788 --
[Issue 21634] std.bitmanip: bitfields may generate invalid variable
https://issues.dlang.org/show_bug.cgi?id=21634 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7799 "Fix 21634 - std.bitmanip: bitfields may generate invalid variable" was merged into master: - 88496f733a956d9e6536069d2bde0eef9c226267 by berni44: Fix 21634 - std.bitmanip: bitfields may generate invalid variable https://github.com/dlang/phobos/pull/7799 --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 --- Comment #5 from Vladimir Panteleev --- It would have to be a different function. `thisExePath` returns a string, but what we really need is a file descriptor. (And, we can't return the string literal "/proc/self/exe" from `thisExePath` on Linux, that would break other uses such as reading files adjacent to the program's executable.) --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #4 from ZombineDev --- Could we move it to druntime and then make it use `/proc/self/exe` on Linux? --
[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'
https://issues.dlang.org/show_bug.cgi?id=15136 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/phobos pull request #7806 "fix issue 15136 - If we want toStringz to be fully correct, it needs …" was merged into master: - c55ce44705ddac208d5d7340b60ad2f8eacd0552 by aG0aep6G: fix issue 15136 - If we want toStringz to be fully correct, it needs to stop checking for '\0' https://github.com/dlang/phobos/pull/7806 --
[Issue 21655] win32 dialog app, main dialog box is not centered
https://issues.dlang.org/show_bug.cgi?id=21655 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #1 from Adam D. Ruppe --- Do you have a resource file to go with the code btw? --
[Issue 21657] New: MmFile cannot map empty files
https://issues.dlang.org/show_bug.cgi?id=21657
Issue ID: 21657
Summary: MmFile cannot map empty files
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: deadal...@gmail.com
First, let's create an empty file:
$ touch me
Now let's run the following sample code:
int main(string[]) {
import std.mmfile;
scope f = new MmFile("me");
return 0;
}
It fails with the following error:
std.exception.ErrnoException@std/mmfile.d(351): Could not map file me (Invalid
argument)
Now, let's add some content to our file
$ echo love > me
Running the program again now works as expected.
--
[Issue 21654] CodeCov build already finished
https://issues.dlang.org/show_bug.cgi?id=21654 --- Comment #4 from Dlang Bot --- dlang/dmd pull request #12221 "Workaround for issue 21654 - CodeCov build already finished" was merged into master: - d1a826ae5f1c05bea8b8fdfd1605e235bf5f7cf8 by MoonlightSentinel: Workaround for issue 21654 - CodeCov build already finished Try adding the Azure/Cirrus jobs to the job count and expected CI's. Upstream issue: https://github.com/codecov/codecov-bash/issues/411 https://github.com/dlang/dmd/pull/12221 --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 --- Comment #3 from Vladimir Panteleev --- BTW, not sure about other systems, but on Linux, reading /proc/self/exe is going to be more reliable than via thisExePath. The reason being that /proc/self/exe is a special directory entry which continues to be valid (openable) even when the target that it (as a symlink) is pointing at is gone. So, perhaps just moving thisExePath to Druntime is not the best option. --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 --- Comment #2 from Vladimir Panteleev --- (In reply to kinke from comment #1) > (though that hasn't changed in the linked druntime PR) But, why would bisection point to that PR as the earliest point for the observed SIGBUS, then? > Too bad `std.file.thisExePath()` is in Phobos and thus not usable. I don't see why it couldn't be moved to Druntime. It looks like it would be a good fit. --
[Issue 21656] [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from kinke --- This seems to boil down to the usage of `program_invocation_name` on Linux to obtain the name of the executable file (though that hasn't changed in the linked druntime PR). It's apparently just `argv[0]` and so not really robust. Not sure if BSD's `getprogname()` is better in this regard. Too bad `std.file.thisExePath()` is in Phobos and thus not usable. --
[Issue 21656] New: [REG2.091] Wrong file read during exception stringification leads to SIGBUS
https://issues.dlang.org/show_bug.cgi?id=21656
Issue ID: 21656
Summary: [REG2.091] Wrong file read during exception
stringification leads to SIGBUS
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
/// bug.d //
void main()
{
try
throw new Exception("Test");
catch (Exception e)
e.toString();
}
To reproduce:
dmd bug.d && mkdir -p a && cd a && touch bug && PATH=.. bug
Introduced in https://github.com/dlang/druntime/pull/2330
There might be two bugs here:
1. The wrong file is being read. This is the more important bug. It might
contain something else entirely, or even point to something that the problem
really should not access. (In my case, it pointed to a directory hosting a FUSE
filesystem provided by the program - so it therefore had the same name as the
program - which led to a deadlock.)
2. Perhaps an empty file should not cause a SIGBUS. The executable file may
have been modified between the point when the program was started and when
Druntime attempts to read it. For example, if the developer is recompiling the
program while an older instance is still running, said instance could
conceivably see an empty file as the compiler is writing the new version.
--
[Issue 21654] CodeCov build already finished
https://issues.dlang.org/show_bug.cgi?id=21654 moonlightsenti...@disroot.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --
[Issue 21655] New: win32 dialog app, main dialog box is not centered
https://issues.dlang.org/show_bug.cgi?id=21655
Issue ID: 21655
Summary: win32 dialog app, main dialog box is not centered
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: top...@139.com
A simple win32 dialog app, compiled by DMD 2.095.1, the dialog box is showed at
upper-left of desktop when startup, but compiled by LDC 1.24.0 one centered.
import core.sys.windows.windows;
import core.runtime;
enum { IDD_DIALOG1 = 100, }
HINSTANCE hiApp;
HWND hwDlg;
extern (Windows) nothrow @system
INT_PTR DlgProc(HWND hw, UINT wm, WPARAM wp, LPARAM lp) {
switch(wm) {
case WM_INITDIALOG:
hwDlg = hw;
return TRUE;
case WM_CLOSE:
EndDialog(hw, 0);
return TRUE;
default:
break;
}
return FALSE;
}
extern (Windows)
INT_PTR WinMain(HINSTANCE hiThis, HINSTANCE hiPrev, LPSTR psArg, int iShow) {
Runtime.initialize();
hiApp = hiThis;
INT_PTR res = DialogBox(hiApp, MAKEINTRESOURCE(IDD_DIALOG1), NULL, );
Runtime.terminate();
return res;
}
--
[Issue 21654] CodeCov build already finished
https://issues.dlang.org/show_bug.cgi?id=21654 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #3 from RazvanN --- Since this is an upstream error, should we close this as "MOVED" ? --
