[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376
--- Comment #4 from kenn...@gmail.com 2011-07-25 03:45:24 PDT ---
The segfault for case 2 happens in _d_throwc:
// this is a catch handler (no finally)
auto pci = cast(DCatchInfo *)(cast(char *)handler_table + phi.cioffset);
auto ncatches = pci.ncatches;
for (int i = 0; i < ncatches; i++)
{
auto ci = **cast(ClassInfo **)h; // <- this line, *h == null
auto pcb = &pci.catch_block[i];
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4591] Concat of std.typecons.Tuples
http://d.puremagic.com/issues/show_bug.cgi?id=4591
--- Comment #1 from bearophile_h...@eml.cc 2011-07-25 05:30:07 PDT ---
Slicing too is sometimes useful:
import std.typecons;
void main() {
auto t1 = tuple(10, 20, 30, 40, 50);
auto t2 = tuple(100, 200, 300);
auto t3 = t1[0 .. 2]; // tuple slicing
auto t4 = t1 ~ t2;// tuple concat
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #5 from bearophile_h...@eml.cc 2011-07-25 05:32:10 PDT --- I approve this enhancement request. In this case if you don't want an error you just don't use to!(). I think to!() is meant to be a safe cast (reminder: safe != memory safe). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376
--- Comment #5 from kenn...@gmail.com 2011-07-25 06:05:42 PDT ---
(In reply to comment #4)
> The segfault for case 2 happens in _d_throwc:
>
> // this is a catch handler (no finally)
>
> auto pci = cast(DCatchInfo *)(cast(char *)handler_table + phi.cioffset);
> auto ncatches = pci.ncatches;
> for (int i = 0; i < ncatches; i++)
> {
> auto ci = **cast(ClassInfo **)h; // <- this line, *h == null
>
> auto pcb = &pci.catch_block[i];
Actually this is because I compile with -debug. Without -debug, _d_throwc is
not no-return, causing originally unreachable statements e.g.
extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ )
{
if( assertHandler is null )
throw new AssertError( file, line );
assertHandler( file, line, null); // < this line
}
to be run.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6378] New: Overriding opAssign disables ability to null a reference
http://d.puremagic.com/issues/show_bug.cgi?id=6378
Summary: Overriding opAssign disables ability to null a
reference
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2011-07-25
07:35:28 PDT ---
class Foo
{
void opAssign(int bar)
{
}
}
void main()
{
auto foo = new Foo;
foo = null;
}
test.d(11): Error: function test.Foo.opAssign (int bar) is not callable using
argument types (void*)
test.d(11): Error: cannot implicitly convert expression (null) of type void* to
int
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6379] New: std.container.SList fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=6379 Summary: std.container.SList fails to compile Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: htven...@gmail.com --- Comment #0 from Harry Vennik 2011-07-25 07:35:50 PDT --- (line numbers for Phobos as it comes with D 2.054) On std/container.d line 944, the definition of SList.Range.empty is missing @property. This makes the definition of linearRemove on line 1287 fail to compile: std/container.d(1288): Error: template instance Take!(Range) does not match any template declaration std/container.d(1287): Error: Take!(Range) is used as a type -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3952] pragma(msg,...) has bugs + alternative idea
http://d.puremagic.com/issues/show_bug.cgi?id=3952 --- Comment #5 from bearophile_h...@eml.cc 2011-07-25 08:35:25 PDT --- See also the discussion here: https://github.com/D-Programming-Language/dmd/pull/237 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Expose the CTFE interpter in Phobos?
(This post is related to something I have suggested time ago, to offer some parts of the D compiler through the D standard library itself (to use the compiler at run-time for some purposes), as recent versions of C#-dotnet too do.) There is a part of the D compiler that to me seems more useful than other ones, I mean the D interpreter used for CTFE. People often add Lua, Python, MiniD, JavaScript to large C/C++/D programs (I think most video games contain some kind of interpreter). So is it possible to offer this part alone to the D programmer? With it you are allowed to create at runtime small strings of D code and interpret it. No need to learn and add a second scripting language to do it. Just import a function execute() from a Phobos module :-) The (hopefully) introduction of some writing function (http://d.puremagic.com/issues/show_bug.cgi?id=3952 https://github.com/D-Programming-Language/dmd/pull/237 ) will make run-time D interpretation even more useful. There are disadvantages: - Even with some printing function, CTFE interpreter is limited. Don will remove some more CTFE limitations like allowing classes and exceptions, but a "scripting language" that can't read and save files is less useful; so maybe it can't fully replace a Lua interpreter. - If you want to use this feature you need the whole D compiler at run time too. The D compiler is probably much bigger than a Lua interpreter. On the other hand maybe it's possible to push the CTFE interpreter in a DLL that is normally used by the D compiler, that the D standard library uses if you want to interpret D code at run time. I don't know if this DLL is going to be small enough. - CTFE is currently much slower than dynamic/scripting languages like LuaJIT (that are becoming almost as fast as well compiled D). But in LDC with the LLVM back-end you have all the tools to create a JIT for interpted D code too :-) LLVM is not a compiler, it's an aggregate of parts. - D language is not as simple as a scripting language. In video games the people that write the 3D engine in C++ are not the same people that program game logic in Lua. The second group of people has different skills, and they often are not good programmers able to write C++ code too. So among other things Lua is used to allow a large number of people to write how the game has to act, not just hard-core C++ programmers. Do you know/have use cases for running D code (with current or near-future CTFE limitations) at run-time? Bye, bearophile
Re: Expose the CTFE interpter in Phobos?
Please ignore this post, the web interface is now more buggy than it used to be. Sorry, bearophile
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 --- Comment #6 from Jonathan M Davis 2011-07-25 09:07:54 PDT --- When talking about safe in D, it means memory safe. That's what @safe is for. As such, if you mean something _other_ than memory safe, you need to be more specific. Otherwise, talking about safe becomes kind of meaningless, because it could mean just about anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3952] pragma(msg,...) has bugs + alternative idea
http://d.puremagic.com/issues/show_bug.cgi?id=3952
--- Comment #6 from BCS 2011-07-25 10:13:37 PDT
---
I don't have a github account so I'll comment here: There is use for ways to
create output at runtime, CTFE time and static expansion time. For instance
this function:
int TemplateCTFE(T...)(int j) {
for (int i = 0; i < j; i++) {
foreach(t; T) {
pragma(msg, t.stringof);
}
}
}
When called like this from a CTFE context:
TemplateCTFE!(int, char, float)(5);
will only print "int\nchar\float" once rather than 5 times. IMHO this
static-expansion-time ouput is more valuable than a CTFE time output (that
would output 15 line from that call). OTOH, having both would be really nice.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3952] pragma(msg,...) has bugs + alternative idea
http://d.puremagic.com/issues/show_bug.cgi?id=3952 --- Comment #7 from bearophile_h...@eml.cc 2011-07-25 10:47:25 PDT --- (In reply to comment #6) > OTOH, having both would be really nice. There are no plans to remove pragma(msg) :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376
--- Comment #6 from kenn...@gmail.com 2011-07-25 10:52:50 PDT ---
Actually my initial guess is right. The bug is due to corruption of the
Throwable object -- in particular its classinfo -- from the
defaultTraceHandler.
Using this:
extern (C) void rt_setTraceHandler(Throwable.TraceInfo function(void*
ptr));
void main() {
rt_setTraceHandler(null);
// rest of main
makes the segfault go away (and the stack trace too).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 Andrei Alexandrescu changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #7 from Andrei Alexandrescu 2011-07-25 10:59:52 PDT --- (In reply to comment #6) > When talking about safe in D, it means memory safe. That's what @safe is for. > As such, if you mean something _other_ than memory safe, you need to be more > specific. Otherwise, talking about safe becomes kind of meaningless, because > it > could mean just about anything. Agreed. That being said, generally std.conv.to is meant to bring additional protection compared to a cast and to memory safety. Probably rejecting conversion from negative int to uint is a good decision. If one doesn't care, one can always use a cast instead. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376 kenn...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #7 from kenn...@gmail.com 2011-07-25 11:47:29 PDT --- druntime pull #42. https://github.com/D-Programming-Language/druntime/pull/42 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6380] New: Proposal to make 'shared usable
http://d.puremagic.com/issues/show_bug.cgi?id=6380
Summary: Proposal to make 'shared usable
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: htven...@gmail.com
--- Comment #0 from Harry Vennik 2011-07-25 12:10:01 PDT
---
I very much like the idea of the transitive shared attribute in D, but in
practice it turns out to be a real pain in the ass. Just try once to write a
class A that will work fine both as just 'A' and as 'shared(A)'. If you're very
lucky you just have to duplicate all your code in 'shared' methods.
Now think of class A as a container type. Need it be different for A and
shared(A)? Apart from synchronisation, no.
Even Phobos' container types Just Don't Work when marked as shared. But shared
data is usually meant to be used somehow, doesn't it? So here is my proposal
for a solution to most of the trouble:
If a non-static member function is called and the following is all true:
- 'this' is shared
- there is no matching 'shared' overload for the function being called
then do the following:
- search for a matching overload that is not marked as shared
- if found, check it semantically as if it were marked as shared
- if it passes the check, use it, but call it through a synchronisation wrapper
Here, calling through a synchronisation wrapper works like this:
// Assuming:
shared(A) a = cast(shared) new A();
// The following …
a.foo()
// … will expand to:
synchronized(a) { a.foo() }
Feel free to comment!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5161] Selective import results in conflicting definition.
http://d.puremagic.com/issues/show_bug.cgi?id=5161
Piotr Szturmaj changed:
What|Removed |Added
CC||psztur...@tlen.pl
Platform|Other |x86
Version|D1 |D2
Severity|normal |regression
--- Comment #2 from Piotr Szturmaj 2011-07-25 14:40:09 PDT
---
I can confirm this bug in 2.054.
Other test case (phobos+dmd 2.054):
--
module main;
import std.socket;
import core.time;
void test(Duration d) {}
void main() {}
--
main.d(6): Error: std.socket.Duration at
D:\dmd2\windows\bin\..\..\src\phobos\std\socket.d(44) conflicts with
core.time.Duration at
D:\dmd2\windows\bin\..\..\src\druntime\import\core\time.di(35)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5161] Selective import results in conflicting definition.
http://d.puremagic.com/issues/show_bug.cgi?id=5161 Christian Kamm changed: What|Removed |Added CC||kamm-removethis@incasoftwar ||e.de --- Comment #3 from Christian Kamm 2011-07-25 15:37:29 PDT --- The fix to bug 314 would fix this as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #22 from bearophile_h...@eml.cc 2011-07-25 19:56:30 PDT --- Two quite useful use cases: A) int[] array = [1, 2]; // dynamic array auto (x, y) = array; // raises a run-time exception if array.length != 2 B) auto (x, y, z) = iota(3); // raises a run-time exception if the lazy Range doesn't yield exactly 3 itens. Is it possible to support them too? Regarding those run-time errors for those assignments, they are already present in the language: int[] array = [1, 2, 3]; int[2] a2 = array[]; object.Exception@src\rt\arraycat.d(31): lengths don't match for array copy -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #23 from Andrei Alexandrescu 2011-07-25 21:03:44 PDT --- (In reply to comment #22) > Two quite useful use cases: > > A) > int[] array = [1, 2]; // dynamic array > auto (x, y) = array; // raises a run-time exception if array.length != 2 No please. Too much magic for the benefit. > B) > auto (x, y, z) = iota(3); // raises a run-time exception if the lazy Range > doesn't yield exactly 3 itens. No please. I'd say let's not go overboard. auto (names) = initializer; sounds like the good thing to do, so let's do it. The rest are considerably more tenuous. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5533] DMD segv: -gc, associative arrays, const pointers to self
http://d.puremagic.com/issues/show_bug.cgi?id=5533 --- Comment #2 from Russ Lewis 2011-07-25 21:45:17 PDT --- I tested this on 2.054 (Linux: Fedora 14 x86 32-bit), and the problem still exists. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6308] Destruction of temporaries on exception causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=6308
--- Comment #5 from Vladimir Panteleev 2011-07-25
23:26:22 PDT ---
(In reply to comment #4)
> I'll try to minimize it.
Reduced it to a small variation of the above.
struct C
{
void oops()
{
throw new Exception("Oops!");
}
~this()
{
}
}
void main()
{
C().oops();
}
I think DustMite may have taken some shortcuts while reducing Andrej's test
case, though - but this test case definitely does show that it's not about
throwing in a constructor.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6308] Destruction of temporaries on exception causes unhandled access violation
http://d.puremagic.com/issues/show_bug.cgi?id=6308 Vladimir Panteleev changed: What|Removed |Added Summary|Destruction of temporaries |Destruction of temporaries |on exception causes |on exception causes |segfault|unhandled access violation --- Comment #6 from Vladimir Panteleev 2011-07-25 23:28:29 PDT --- By the way, I should probably clearly mention that this is Windows-only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
