[Issue 3920] Assertion failure: '0' on line 10018 in file 'expression.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3920 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2010-03-10 23:56:41 PST --- The patch for bug 3919 fixes this one, too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3884] Segfault: defining a typedef with an invalid object.d
http://d.puremagic.com/issues/show_bug.cgi?id=3884 Matti Niemenmaa matti.niemenmaa+dbugzi...@iki.fi changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Summary|Segfault: typedef present |Segfault: defining a |when passing array in tuple |typedef with an invalid |argument to function|object.d |template| --- Comment #2 from Matti Niemenmaa matti.niemenmaa+dbugzi...@iki.fi 2010-03-11 02:34:40 PST --- Took me a while to reproduce it again myself. It's quite different from what I reported: I had an invalid object.d in the working directory, which triggers it. It seems the typedef alone is enough, the array and tuple business is unneeded: $ cat arst.d typedef int X; $ dmd -c arst.d [no errors] $ touch object.d $ dmd -c arst.d E: Child terminated by signal ‘Segmentation fault’ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3929] GC.free() creates subtle bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3929 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-03-11 03:43:16 PST --- Hm... first off, the LRU cache is only used for appending. So in order for the LRU cache to mistakenly access unallocated memory, you must be appending to an invalid array. Second, the LRU cache stores blockinfos, which should never change except in one case. That one case is when an array greater than half a page size is appended to, it can grow in place by appending more pages to the blockinfo. This means a stale blockinfo could identify a memory block as being larger or smaller than it actually is. I would expect AA nodes to be small enough to not trigger this problem. If you clear the cache on a GC run, then you remove the cache's usefulness since a GC run occurs only when new memory is requested. If you clear it on GC free, you have to stop all threads. I don't think either of these solutions will work, but I also don't think the LRU cache is causing problems. Can we try to disable the cache to rule it out? I suspect there is another issue with AA's related to the appending fix, but I think it has to do with the fact that AAs are allocating arrays without using the runtime functions for arrays (it calls GC.malloc directly and builds the array structure manually). The only trouble is, I see the only place where arrays are appended (via adding to the length) is in the rebalance function. This seems to coincide with another bug report (bug 3898) but the array starts out as a static array, so unless the stack frame is heap allocated (which it should *not* be), the append patch should work properly. I will create some patches to disable the cache and the whole array stomping fix, and see if either of those makes the problem go away. If not, then we have to look elsewhere. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3930] AAs horribly broken
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2010-03-11 04:07:31 PST --- I can only find two places that AA's use free, one when an element is removed via gc_free, and once to delete the hash array itself. Commenting out both of those, I still get the segmentation fault. I'm still not convinced that the stomping fixes I put in are not to blame, I will try commenting those out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3898] access violation with associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3898 --- Comment #2 from Rainer Schuetze r.sagita...@gmx.de 2010-03-11 05:42:04 PST --- Somehow I could not reproduce it with this test case, but it still happened with the larger project that showed the problem to begin with. After applying your fix, it back up and running. Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3898] access violation with associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3898 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2010-03-11 05:44:03 PST --- OK, great. I'll mark this as a duplicate of 3930 so we only track it in one place. *** This issue has been marked as a duplicate of issue 3930 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3930] AAs horribly broken
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2010-03-11 05:44:03 PST --- *** Issue 3898 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3932] New: Title: A forward declaration error with a struct.init
http://d.puremagic.com/issues/show_bug.cgi?id=3932
Summary: Title: A forward declaration error with a struct.init
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-11 06:31:58 PST ---
This D2 code:
template Foo(alias something) {
enum bool Foo = true;
}
struct S {
int x;
}
static assert(Foo!(S())); // OK
static assert(Foo!(S.init)); // Error
void main() {}
Raises the following errors:
bug.d(4): Error: declaration _D3bug1S6__initZ forward declaration
bug.d(8): Error: template instance bug.Foo!(_D3bug1S6__initZ) error
instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3867] Regression(1.051): forward referenced enum member via an alias, templates, and is()
http://d.puremagic.com/issues/show_bug.cgi?id=3867
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Summary|pragma(msg) with a forward |Regression(1.051): forward
|referenced enum member via |referenced enum member via
|an alias, templates,|an alias, templates, and
|tuples, and CTFE|is()
--- Comment #7 from Don clugd...@yahoo.com.au 2010-03-11 08:12:01 PST ---
Reduced test case shows it has nothing to do with tuples or CTFE. Can probably
be simplified further.
This worked in 1.050, but failed in 1.051.
enum ArrayFlags {
None =0,
}
class red(int rank) {
uint flags = Flags.None;
alias ArrayFlags Flags;
}
void violet(Y) (red!(2) b) {
static assert (!is(red!(7) : red!(3)));
}
void main(){
violet!(int)(null);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3808] Assertion Failure : Assertion failure: 'classinfo-structsize == CLASSINFO_SIZE' on line 870 in file 'toobj.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3808 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||ice-on-invalid-code CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2010-03-11 08:18:50 PST --- This is caused by an incorrectly installed DMD (wrong phobos.lib). However, the compiler should say that, instead of failing with an assert). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3933] New: Array memory allocation error lacks a line number
http://d.puremagic.com/issues/show_bug.cgi?id=3933
Summary: Array memory allocation error lacks a line number
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-11 12:19:14 PST ---
This program:
void main() {
int[] a;
a.length -= 1;
}
At runtime the compiler shows the following error message, if possible I'd like
to see a line number too:
Memory allocation failed
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3914] Struct as argument that fits in register has member accessed wrong
http://d.puremagic.com/issues/show_bug.cgi?id=3914
--- Comment #1 from Don clugd...@yahoo.com.au 2010-03-11 12:51:37 PST ---
Here's a slightly reduced test case which doesn't require any compiler flags.
Not a regression, fails even on DMD0.165.
It's a problem with variadic function parameters and fastpar arguments.
struct SS {
char a, b, c, d;
}
void show(char[] args...) {
assert(args[0]=='A');
assert(args[1]=='L');
assert(args[2]=='D');
assert(args[3]=='O');
}
void A( SS ss ) {
show( ss.a, ss.b, ss.c, ss.d );
}
void main(){
SS ss3;
ss3.a = 'A';
ss3.b = 'L';
ss3.c = 'D';
ss3.d = 'O';
A( ss3 );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3934] New: Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
Summary: Some untidy attributes
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid, rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-11 14:08:26 PST ---
This D2 program compiles and runs with no errors or warnings:
static foo1() {}
final foo2() {}
ref foo3() {}
enum void foo4() {}
nothrow foo5() {}
pure foo6() {}
static int x1 = 10;
static x2 = 10;
void main() {}
Notes:
- foo1, x1, x2: I don't know what a static global void function/variable is in
D2, so 'static' can be disallowed for global functions/variables.
- foo2, foo3, foo4: they look like bugs.
- Are most of those attributes supposed to not need the void? I think
requiring for example pure void is a little better than allowing just pure.
The following lines don't compile, is this correct?
int static x3 = 10;
int enum x4 = 1;
int const x5 = 2;
I like the strictness of the Java compiler, it makes sure your attributes are
all correct and meaningful, this helps avoid possible bugs. And I'm sure it
helps newbies learn the language in less time too (because when you don't know
the rules yet, it's very useful if they don't change).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3921] Compile time evaluation requirements not well-specified
http://d.puremagic.com/issues/show_bug.cgi?id=3921 --- Comment #2 from Jerry Quinn jlqu...@optonline.net 2010-03-11 15:21:50 PST --- (In reply to comment #1) Quoting the spec: In order to be executed at compile time, the function must appear in a context where it must be so executed Note the word MUST. I don't see anything in the spec to indicate that it is optional. No, the language above says that the correct function context is necessary, not sufficient. CTFE won't succeed unless the condition is met. It definitely does not say that the compiler is required to try. It's pretty simple actually -- if the compiler *needs* a constant, and it sees an expression, it attempts to constant-fold that expression. If the expression contains a function call, CTFE will be used. CTFE is not used in any other context - it never happens unless requested. In principle, it's simple. But typically constant folding is an optimization, not a requirement in languages, so D is relatively unique in this regard. It's important for the spec to explicitly say so rather than imply through example. Other writing I've seen suggests that CTFE is an optimization, not a language requirement. Can you remember where you saw that writing, or got that impression? If it's anywhere public, we need to get rid of it, since it is not correct. I can't find what I thought I read about. So it's possible I hallucinated that and it's a false impression. I still think that the fact that the compiler is guaranteed to execute expressions and functions at compile time has to be more clearly stated, though. Also, the rules for expressions to be executed at compile time should also be explicitly stated, separate from the function rules. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3929] GC.free() creates subtle bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3929 --- Comment #4 from David Simcha dsim...@yahoo.com 2010-03-11 16:41:52 PST --- What about the issue of unnecessary GC retention of (possibly large) arrays? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3935] New: opBinary is instantiated with =
http://d.puremagic.com/issues/show_bug.cgi?id=3935
Summary: opBinary is instantiated with =
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r mrmoc...@gmx.de 2010-03-11 16:50:40 PST ---
This is really strange behavior. It gets even stranger over time.
It once started with
Vector2f_pos = Vector2f(0.f, 0.f);
yields:
Error: template instance opBinary!(=) matches more than one template
declaration
Now I can't seem to reproduce it anymore.
But in a bigger project, with the following code:
Vector2 opBinary(string op, U:Vector2)(U v)
{
pragma(msg, opBinary!~op);
}
I get several instantiations with opBinary!=
Even though http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
clearly states that = isn't overloadable which totally makes sense since
there is http://www.digitalmars.com/d/2.0/operatoroverloading.html#Assignment
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3935] opBinary is instantiated with =
http://d.puremagic.com/issues/show_bug.cgi?id=3935
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2010-03-11 18:06:04 PST ---
When you submit a bug it's better to show a minimal but complete program that
shows your problem. This shows the situation (I think it's cute, an
undocumented operator overload):
struct Foo {
void opBinary(string op)(Foo other) {
pragma(msg, op: ~ op);
}
}
void main() {
Foo f;
f = f;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3929] GC.free() creates subtle bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3929 --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com 2010-03-11 18:08:26 PST --- The cache actually depends on it. If the block info in the cache is freed and then reallocated as smaller blocks, using append may utilize a stale blockinfo and allow overwriting of data that is not allocated to the array. I agree the situation is not ideal. Do you have any ideas on how to fix it? One possibility is to allow manual clearing of the cache if you want to tune the application. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3929] Interactions between LRU array cache, memory recycling
http://d.puremagic.com/issues/show_bug.cgi?id=3929 David Simcha dsim...@yahoo.com changed: What|Removed |Added Summary|GC.free() creates subtle|Interactions between LRU |bugs|array cache, memory ||recycling --- Comment #6 from David Simcha dsim...@yahoo.com 2010-03-11 19:00:55 PST --- Well, -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3929] Interactions between LRU array cache, memory recycling
http://d.puremagic.com/issues/show_bug.cgi?id=3929 --- Comment #7 from David Simcha dsim...@yahoo.com 2010-03-11 19:07:16 PST --- Well, there are really two issues here: What happens when GC.free() gets called and what happens when the GC collects. As much as people (Andrei comes to mind) hate it from a theoretical purity point of view, I believe it's absolutely necessary to be able to GC.free() a large array while the GC sucks as bad as it currently does. For the GC collection case I still don't understand what's wrong with clearing the LRU. If I understand how this stuff works correctly, the information is also stored at the end of every block, so on the next append the cache will be repopulated. It will only cost one non-cached lookup per array per GC collection. For the GC.free() case you raise a very good point about thread safety. I really don't have a good answer for it. Calling free() doesn't have to be cheap, but stopping the world is a little too expensive. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3791] Reference anonymous nested classes when describing new expressions
http://d.puremagic.com/issues/show_bug.cgi?id=3791 --- Comment #1 from Jerry Quinn jlqu...@optonline.net 2010-03-11 19:50:00 PST --- A couple of words should be associated with PostfixExpression as well, since that's where nested class new syntax actually shows up in the grammar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
