digitalmars.D - Howto build a repo case for a ICE?
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- "Daniel Murphy" <yebblies nospamgmail.com> Feb 19 2012
- Timon Gehr <timon.gehr gmx.ch> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 19 2012
- "Vladimir Panteleev" <vladimir thecybershadow.net> Feb 21 2012
- Don <nospam nospam.com> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- "Daniel Murphy" <yebblies nospamgmail.com> Feb 19 2012
- Benjamin Thaut <code benjamin-thaut.de> Feb 19 2012
- bearophile <bearophileHUGS lycos.com> Feb 19 2012
The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c' Kind Regards Benjamin Thaut
Feb 19 2012
There are only a few options: - Reduce your code using dustmite. I've never tried this, but I hear it works. - Use a debug version of dmd, or post the code and hope someone else debugs it. - Reduce the code manually. The error you're getting occurs when merging two integral types together, and something goes horribly wrong. It shouldn't be happening, but I'd guess it's something to do with alias this with integral types (huge guess). How big is the project? "Benjamin Thaut" <code benjamin-thaut.de> wrote in message news:jhqt5p$1uel$1 digitalmars.com...The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c' Kind Regards Benjamin Thaut
Feb 19 2012
On 02/19/2012 02:24 PM, Benjamin Thaut wrote:The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c' Kind Regards Benjamin Thaut
DustMite is an useful tool for generating reduced cases that cause the same ICE: https://github.com/CyberShadow/DustMite
Feb 19 2012
Am 19.02.2012 14:44, schrieb Timon Gehr:On 02/19/2012 02:24 PM, Benjamin Thaut wrote:The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c' Kind Regards Benjamin Thaut
DustMite is an useful tool for generating reduced cases that cause the same ICE: https://github.com/CyberShadow/DustMite
Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
Feb 19 2012
Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
Yes, it never crashes at the extact same reduction step, but it always crashes somewhere in between. I assume that it is a segfault because it does not print a stack trace. I could however only test it on 1 machine so it could be machine specific.
Feb 19 2012
Am 19.02.2012 18:25, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 16:11:35 UTC, Benjamin Thaut wrote:Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
Yes, it never crashes at the extact same reduction step, but it always crashes somewhere in between. I assume that it is a segfault because it does not print a stack trace. I could however only test it on 1 machine so it could be machine specific.
I'd appreciate it if you could gather more information about the crash (for example, running in in a debugger so you can get the backtrace of the segfault, if there is one).
rmdirRecurse which gets called in dustmite.d line 457 throws a exception that causes the D exception handler to go into inifnite recursion which leads to a stack overflow and crashes the program. Might be a issue with my file system. Going to do a file system check. Kind Regards Benjamin Thaut
Feb 19 2012
Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
I've made the experience that it is more-or-less impossible to run dustmite on windows for longer time spans. The cause is most probably Windows Explorer, which sometimes accesses and locks files. In a project we wrote a limited retry-loop around the critical file system calls to get stable runs...
Feb 19 2012
Am 20.02.2012 01:40, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 22:46:29 UTC, Sönke Ludwig wrote:Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
I've made the experience that it is more-or-less impossible to run dustmite on windows for longer time spans. The cause is most probably Windows Explorer, which sometimes accesses and locks files. In a project we wrote a limited retry-loop around the critical file system calls to get stable runs...
I've never encountered such problems. DustMite can run for days on end without issues.
If I run it inside my C:\Users\<my username>\Documents directory it does not wrong very long. 10 mins max before it crashes. Now I put my sourcecode directly in the root of a partition F:\ and it works just fine without crashing once in hours. Kind Regards Benjamin Thaut
Feb 19 2012
On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
Feb 19 2012
On Sunday, 19 February 2012 at 16:11:35 UTC, Benjamin Thaut wrote:Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
Yes, it never crashes at the extact same reduction step, but it always crashes somewhere in between. I assume that it is a segfault because it does not print a stack trace. I could however only test it on 1 machine so it could be machine specific.
I'd appreciate it if you could gather more information about the crash (for example, running in in a debugger so you can get the backtrace of the segfault, if there is one).
Feb 19 2012
On Sunday, 19 February 2012 at 17:56:42 UTC, Benjamin Thaut wrote:rmdirRecurse which gets called in dustmite.d line 457 throws a exception that causes the D exception handler to go into inifnite recursion which leads to a stack overflow and crashes the program. Might be a issue with my file system. Going to do a file system check.
One of the reasons that rmdirRecurse might fail is if a program has opened the directory or one of the files. This may be caused by trying to peek at Dustmite's results while it's running without pausing it, or perhaps antivirus/antimalware software.
Feb 19 2012
On Sunday, 19 February 2012 at 17:56:42 UTC, Benjamin Thaut wrote:rmdirRecurse which gets called in dustmite.d line 457 throws a exception that causes the D exception handler to go into inifnite recursion which leads to a stack overflow and crashes the program.
Thanks for taking the time to figure this out. I'll make DustMite catch rmdirRecurse failures and retry the operation (as the causes are usually temporary).
Feb 19 2012
On Sunday, 19 February 2012 at 22:46:29 UTC, Sönke Ludwig wrote:Am 19.02.2012 17:06, schrieb Vladimir Panteleev:On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:Which dmd version should I use to build DustMite? I tried 2.055 and 2.058 but DustMite crashes half way through the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMite crash reproducible?
I've made the experience that it is more-or-less impossible to run dustmite on windows for longer time spans. The cause is most probably Windows Explorer, which sometimes accesses and locks files. In a project we wrote a limited retry-loop around the critical file system calls to get stable runs...
I've never encountered such problems. DustMite can run for days on end without issues.
Feb 19 2012
On Sunday, 19 February 2012 at 21:42:17 UTC, Vladimir Panteleev wrote:On Sunday, 19 February 2012 at 17:56:42 UTC, Benjamin Thaut wrote:rmdirRecurse which gets called in dustmite.d line 457 throws a exception that causes the D exception handler to go into inifnite recursion which leads to a stack overflow and crashes the program.
Thanks for taking the time to figure this out. I'll make DustMite catch rmdirRecurse failures and retry the operation (as the causes are usually temporary).
https://github.com/CyberShadow/DustMite/commit/e2d91dab03b7c98dfbacbbc41f7cf49d3935fd35
Feb 21 2012
On 19.02.2012 14:24, Benjamin Thaut wrote:The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c'
If you don't mind building the compiler, add this line just before 2082: if (t1->ty != t2->ty) e1->error("ICE"); and then build the compiler. Sorry for the newbie-hostile comment. But it would save you a lot of time.
Feb 19 2012
Am 19.02.2012 15:41, schrieb Don:On 19.02.2012 14:24, Benjamin Thaut wrote:The last dmd version I could use to actually build my project was dmd 2.056. Now I want to help finding those bugs that keep me from compiling and I'm wondering how I can build repro cases for the ICEs I encounter. I tried compiling with -v but that does not really give much information about where the crash actually happens. So I wonder what can actually be done to find the part of the code or even only the module it crashes in? The current ICE I'm encountering is: Assertion failure: 't1->ty == t2->ty' on line 2082 in file 'cast.c'
If you don't mind building the compiler, add this line just before 2082: if (t1->ty != t2->ty) e1->error("ICE"); and then build the compiler. Sorry for the newbie-hostile comment. But it would save you a lot of time.
Thank you very much that helped a lot. I was able to reduce it to the following code: class Foo { property EntityId entityId() { return EntityId(3); } } struct EntityId { uint id; alias id this; this(uint id) { this.id = id; } } int main(string[] argv) { Foo foo = null; auto id = (foo) ? foo.entityId : -1; return 0; }
Feb 19 2012
"Benjamin Thaut" <code benjamin-thaut.de> wrote in message news:jhr584$2d1v$1 digitalmars.com...Thank you very much that helped a lot. I was able to reduce it to the following code: class Foo { property EntityId entityId() { return EntityId(3); } } struct EntityId { uint id; alias id this; this(uint id) { this.id = id; } } int main(string[] argv) { Foo foo = null; auto id = (foo) ? foo.entityId : -1; return 0; }
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message news:jhqua0$20c0$1 digitalmars.com...It shouldn't be happening, but I'd guess it's something to do with alias this with integral types (huge guess). How big is the project?
Damn I'm good.
Feb 19 2012
Am 19.02.2012 16:44, schrieb Daniel Murphy:"Benjamin Thaut"<code benjamin-thaut.de> wrote in message news:jhr584$2d1v$1 digitalmars.com...Thank you very much that helped a lot. I was able to reduce it to the following code: class Foo { property EntityId entityId() { return EntityId(3); } } struct EntityId { uint id; alias id this; this(uint id) { this.id = id; } } int main(string[] argv) { Foo foo = null; auto id = (foo) ? foo.entityId : -1; return 0; }
"Daniel Murphy"<yebblies nospamgmail.com> wrote in message news:jhqua0$20c0$1 digitalmars.com...It shouldn't be happening, but I'd guess it's something to do with alias this with integral types (huge guess). How big is the project?
Damn I'm good.
Create a bug ticket for it: http://d.puremagic.com/issues/show_bug.cgi?id=7545 The bug was introduced because I had to replace a typedef with a wrapper struct. Kind Regards Benjamin Thaut
Feb 19 2012
Benjamin Thaut:Thank you very much that helped a lot. I was able to reduce it to the following code: class Foo { property EntityId entityId() { return EntityId(3); } } struct EntityId { uint id; alias id this; this(uint id) { this.id = id; } } int main(string[] argv) { Foo foo = null; auto id = (foo) ? foo.entityId : -1; return 0; }
Reduced: struct Foo { uint bar; alias bar this; this(int) {} } void main() { auto spam = true ? Foo(1) : 1; } Bye, bearophile
Feb 19 2012









"Daniel Murphy" <yebblies nospamgmail.com> 