Re: Stack overflow checking?
Am Wed, 02 May 2012 02:45:32 +0200 schrieb bearophile bearophileh...@lycos.com: I'd like to open an enhancement request for something like this as a feature for all D compilers, what do you think? (Generally Ada has something to teach to D design): http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Stack-Overflow-Checking.html Thank you, bye, bearophile I'm not opposed. It is easily possible to segfault an @safe D program with a stack overflow. E.g. not cautious when writing the exit condition in a recursive function. If this can be a proper StackOverflowException somehow, it would be nice. -- Marco
Re: Stack overflow / recursive expansion with alias this
On Tuesday, 24 April 2012 at 20:09:32 UTC, Namespace wrote: On Tuesday, 24 April 2012 at 19:34:26 UTC, Timon Gehr wrote: On 04/24/2012 07:09 PM, Namespace wrote: ... And therefore i get the same error, as if i wrote return NotNull!(Foo)(this); instead of return assumeNotNull(this);, in the _convert method of NotNull. The Output is Stack overflow. I think that comes from recursive calls which fills the stack? Is that a bug? Yes. I found nothing like that. Is the bug reported? I remember reporting a similar issue, but that one seems to have been fixed. Feel free to create a new ticket. That's what I do now. Thanks a lot for your help. Today I posted a pull to detect recursive alias this dependency. https://github.com/D-Programming-Language/dmd/pull/1028 Bye. Kenji Hara
Re: Stack overflow
Wait, you have a template mixin inside of Foo which passes Foo to it? I don't know if you can get away with that or not, since you're trying to pass a type to a template while you're adding stuff to it via that template. So, the type is incomplete. I'm willing to be that that's your problem, but I don't know. - Jonathan M Davis If so, the problem would have to solved if i switch from a mixin to an abstract class. Or not? Or have you any other idea?
Re: Stack overflow
On Monday, June 25, 2012 08:24:59 Namespace wrote: Wait, you have a template mixin inside of Foo which passes Foo to it? I don't know if you can get away with that or not, since you're trying to pass a type to a template while you're adding stuff to it via that template. So, the type is incomplete. I'm willing to be that that's your problem, but I don't know. - Jonathan M Davis If so, the problem would have to solved if i switch from a mixin to an abstract class. Or not? Or have you any other idea? If you don't need to use any compile-time reflection on the type itself (i.e. you just need its name), you can use a string mixin. - Jonathan M Davis
Re: Stack overflow
If you don't need to use any compile-time reflection on the type itself (i.e. you just need its name), you can use a string mixin. - Jonathan M Davis You mean i should pack the whole mixin template in a string? Isn't that a little bit ugly?
Re: Stack overflow
On Monday, June 25, 2012 10:18:19 Namespace wrote: If you don't need to use any compile-time reflection on the type itself (i.e. you just need its name), you can use a string mixin. - Jonathan M Davis You mean i should pack the whole mixin template in a string? Isn't that a little bit ugly? More or less yeah. You generate the code as a string and then mix it in. As it's a string, it's really easy to manipulate, and if you lay out the strings properly, it's not really even particularly hard to read. Personally, I never use template mixins, and I get the impression that string mixins get used a lot more than template mixins do. - Jonathan M Davis
Re: Stack overflow
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting. With or wihtout that, if i add a method to Foo it
prints Stack overflow also.
http://dpaste.dzfl.pl/91dad66c
Can you explain that?
Wait, you have a template mixin inside of Foo which passes Foo to it? I don't
know if you can get away with that or not, since you're trying to pass a type
to a template while you're adding stuff to it via that template. So, the type
is incomplete. I'm willing to be that that's your problem, but I don't know.
- Jonathan M Davis
This is fine. I am doing it all the time.
Why are we discussing this compiler bug on the main newsgroup though?
Re: Stack overflow
On Monday, June 25, 2012 13:01:47 Timon Gehr wrote:
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting. With or wihtout that, if i add a method to Foo it
prints Stack overflow also.
http://dpaste.dzfl.pl/91dad66c
Can you explain that?
Wait, you have a template mixin inside of Foo which passes Foo to it? I
don't know if you can get away with that or not, since you're trying to
pass a type to a template while you're adding stuff to it via that
template. So, the type is incomplete. I'm willing to be that that's your
problem, but I don't know.
- Jonathan M Davis
This is fine. I am doing it all the time.
If it works, then it works, but it surprises me a bit, given that you can't do
that with template declarations normally.
Why are we discussing this compiler bug on the main newsgroup though?
We're not discussing this on the main newsgroup. This is d-learn.
- Jonathan M Davis
Re: Stack overflow
Fine. But nothing of them explain the Stack overflow if i add an additional method or disable/add an additional ctor.
Re: Stack overflow
On 06/25/2012 02:18 PM, Namespace wrote: Fine. But nothing of them explain the Stack overflow if i add an additional method or disable/add an additional ctor. It does not have to be explained: it is a compiler bug.
Re: Stack overflow
On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote: On 06/25/2012 02:18 PM, Namespace wrote: Fine. But nothing of them explain the Stack overflow if i add an additional method or disable/add an additional ctor. It does not have to be explained: it is a compiler bug. Then it will take months or years until it is fixed ... too bad. And that Ref!(Foo) rf = new Foo(); ends even with Stack overflow and Ref!(Foo) rf2 = new Ref!(Foo)(new Foo()); not has the same explanation Compiler Bug, hm?
Re: Stack overflow
Many of them get fixed quite fast if they are reported properly. But since I have had other experiences. But no matter. It is always a compiler bug if compilation crashes. Only that a simple @disable this(typeof(null)); fails, is crap. Because so you cannot test at compile time for such assignments.
Re: Stack overflow
My fault, Ref!(Foo) rf = new Foo(); work as expected.
Re: Stack overflow
A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? And can me explain somebody why [code] @disable this(typeof(null)); [/code] print Stack overflow?
Re: Stack overflow
Am 24.06.2012 11:35, schrieb Namespace: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? And can me explain somebody why [code] @disable this(typeof(null)); [/code] print Stack overflow? What should typeof(null) return you? void*, int*
Re: Stack overflow
On Sunday, 24 June 2012 at 10:37:39 UTC, David wrote: Am 24.06.2012 11:35, schrieb Namespace: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? And can me explain somebody why [code] @disable this(typeof(null)); [/code] print Stack overflow? What should typeof(null) return you? void*, int* I don't understand, what do you mean?
Re: Stack overflow
On 06/24/2012 12:37 PM, David wrote: Am 24.06.2012 11:35, schrieb Namespace: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? And can me explain somebody why [code] @disable this(typeof(null)); [/code] print Stack overflow? What should typeof(null) return you? void*, int* typeof(null) gives typeof(null).
Re: Stack overflow
On Sunday, June 24, 2012 11:35:46 Namespace wrote: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? As I said, it will be added to _Phobos_. So, it will be a struct in the standard library, not in the language itself. It'll probably be NonNullable!T. - Jonathan M Davis
Re: Stack overflow
Am 24.06.2012 13:15, schrieb Timon Gehr: On 06/24/2012 12:37 PM, David wrote: Am 24.06.2012 11:35, schrieb Namespace: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? And can me explain somebody why [code] @disable this(typeof(null)); [/code] print Stack overflow? What should typeof(null) return you? void*, int* typeof(null) gives typeof(null). Right my bad, I was confused a bit
Re: Stack overflow
On Sunday, 24 June 2012 at 11:55:15 UTC, Jonathan M Davis wrote: On Sunday, June 24, 2012 11:35:46 Namespace wrote: A non-nullable type _will_ be added to Phobos at some point. As struct or class or as built-in type? As I said, it will be added to _Phobos_. So, it will be a struct in the standard library, not in the language itself. It'll probably be NonNullable!T. - Jonathan M Davis You can take my Ref struct. ;) And can me now anybody explain why @disable this(typeof(null)); or any other ctor declaration prints stack overflow? How it is possible, that one class and one struct kill the stack?
Re: Stack overflow
On Sunday, June 24, 2012 14:09:38 Namespace wrote: And can me now anybody explain why @disable this(typeof(null)); or any other ctor declaration prints stack overflow? How it is possible, that one class and one struct kill the stack? Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis
Re: Stack overflow
On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote: On Sunday, June 24, 2012 14:09:38 Namespace wrote: And can me now anybody explain why @disable this(typeof(null)); or any other ctor declaration prints stack overflow? How it is possible, that one class and one struct kill the stack? Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis http://dpaste.dzfl.pl/ca77bc96 Comment out alias this in Foo or @disable this(typeof(null)); in Test solve the problem. Otherwise it prints Stack overflow.
Re: Stack overflow
On Sunday, June 24, 2012 14:29:10 Namespace wrote: On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote: On Sunday, June 24, 2012 14:09:38 Namespace wrote: And can me now anybody explain why @disable this(typeof(null)); or any other ctor declaration prints stack overflow? How it is possible, that one class and one struct kill the stack? Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis http://dpaste.dzfl.pl/ca77bc96 Comment out alias this in Foo or @disable this(typeof(null)); in Test solve the problem. Otherwise it prints Stack overflow. My guess is that you've got something recursive going on (possibly a recursive template instantiation, though I don't see any reason why that would occur), which causes it to eat up more and more memory, until the OS kills it. Report it as a dmd bug: http://d.puremagic.com - Jonathan M Davis
Re: Stack overflow
My guess is that you've got something recursive going on (possibly a recursive template instantiation, though I don't see any reason why that would occur), which causes it to eat up more and more memory, until the OS kills it. Report it as a dmd bug: http://d.puremagic.com - Jonathan M Davis All right, but have you any workaround? As long as it endures to fix a bug in dmd, i'm a old men when i can work with it.
Re: Stack overflow
On Sunday, June 24, 2012 14:57:37 Namespace wrote:
My guess is that you've got something recursive going on
(possibly a recursive
template instantiation, though I don't see any reason why that
would occur),
which causes it to eat up more and more memory, until the OS
kills it.
Report it as a dmd bug: http://d.puremagic.com
- Jonathan M Davis
All right, but have you any workaround?
As long as it endures to fix a bug in dmd, i'm a old men when i
can work with it.
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Re: Stack overflow
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting. With or wihtout that, if i add a method to Foo it
prints Stack overflow also.
http://dpaste.dzfl.pl/91dad66c
Can you explain that?
Re: Stack overflow
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting. With or wihtout that, if i add a method to Foo it
prints Stack overflow also.
http://dpaste.dzfl.pl/91dad66c
Can you explain that?
Wait, you have a template mixin inside of Foo which passes Foo to it? I don't
know if you can get away with that or not, since you're trying to pass a type
to a template while you're adding stuff to it via that template. So, the type
is incomplete. I'm willing to be that that's your problem, but I don't know.
- Jonathan M Davis
Re: Stack overflow
On Friday, 22 June 2012 at 23:01:47 UTC, David wrote: Am 22.06.2012 23:11, schrieb Namespace: debugger), but my guess is that Namespace just doesn't know how to do that or that it's even possible - hence his frustration with not getting any information. Exactly. And I use VisualD and the standard debugger of it. Sorry but I would learn how to use the debugger instead (it helps a lot!), instead of implementing features which emulate C++ behaviour (according to your blog) and will confuse people, e.g. if you documentate that, people will be like *huh this cannot be null, is this a feature I don't know?* and end up confused. I would prefer NullPointer Exceptions and / or not null types rather than playing around with the debugger. That's the first step.
Re: Stack overflow
Am 23.06.2012 07:27, schrieb Namespace: I would prefer NullPointer Exceptions and / or not null types rather than playing around with the debugger. That's the first step. Yeah but not implemented by a library.
Re: Stack overflow
On Saturday, 23 June 2012 at 09:53:35 UTC, David wrote: Am 23.06.2012 07:27, schrieb Namespace: I would prefer NullPointer Exceptions and / or not null types rather than playing around with the debugger. That's the first step. Yeah but not implemented by a library. Not yet. ;)
Re: Stack overflow
So here i proudly present my Ref struct (2.0 ;)) http://dpaste.dzfl.pl/905e1d3d So, any suggestions, further ideas or criticism?
Re: Stack overflow
BTW: Any tries to declare @disable this(typeof(null)); end with the same message Stack overflow...
Re: Stack overflow
On Saturday, June 23, 2012 07:27:56 Namespace wrote: I would prefer NullPointer Exceptions and / or not null types rather than playing around with the debugger. That's the first step. NullPointerExceptions (well, they'd end up being NullPointersErrors) will _never_ happen. Walter is completely against them. From his point of view, the OS is _already_ checking this for you (hence the segfault or access violation), so there's no point in having the language check. We might end up with something in druntime which prints out a stacktrace when a segfault occurs, but that's the closest that you'll ever get to a null pointer exception in D. A non-nullable type _will_ be added to Phobos at some point. The issue is a matter of implementation. At least one has been submitted, but it wasn't good enough to be included as it stood. So, it hasn't been merged in. As soon as there is one which is good enough and has been appropriately reviewed by the Phobos devs, we'll have one. But until then, we don't. - Jonathan M Davis
Re: Stack overflow
On 22-06-2012 12:22, Namespace wrote: I have this code: http://codepad.org/vz17iZrm And as long as i comment out the assert's in the constructor on line 10 and the assert in the invariant on line 16 it works as i want. But otherwise the compiler prints stackoverflow and that's all. Why and how is the stack overflowed with an simple assert?! Wow, you really managed to dig up some compiler bugs here. OK, so first of all, if you change the asserts to assert(obj); and assert(_obj); (I assume this is what you meant in the invariant), the code compiles. This is clearly a bug. Now, if you change the first assert to assert(obj); and the one in the invariant to assert(obj); *too* (invalid code), the compiler just plain seg faults. The workaround, as mentioned, is to either use assert(obj); and assert(_obj); or assert(!!obj); and assert(!!_obj);. The reason the latter forms may be desirable is that the former calls obj's invariant in addition to checking for null. The latter doesn't. In any case, please file bugs for these issues. You really managed to run into some unusually broken parts of the compiler, it seems. :-/ -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Stack overflow
On 06/22/2012 12:22 PM, Namespace wrote: I have this code: http://codepad.org/vz17iZrm And as long as i comment out the assert's in the constructor on line 10 and the assert in the invariant on line 16 it works as i want. But otherwise the compiler prints stackoverflow and that's all. Why and how is the stack overflowed with an simple assert?! On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. (BTW, what is 'obj' in the invariant supposed to refer to?)
Re: Stack overflow
On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. My first try to avoid this circular bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code. (BTW, what is 'obj' in the invariant supposed to refer to?) Just for testing. ;) @Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version alias this is more stable.
Re: Stack overflow
Am 22.06.2012 12:52, schrieb Namespace: On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. My first try to avoid this circular bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code. (BTW, what is 'obj' in the invariant supposed to refer to?) Just for testing. ;) @Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version alias this is more stable. I am wondering why you wanna have Objects which will never be null. Use a contract which checks for null and you're done (another benefit, it get's removed if you compile with -release). The only thing you gain from that is an Exception instead of a Segfault, where is the benefit, the app crashes in both cases and if you wanna handle those Exceptions, you can also check for null which is definitly faster and more readable (because it's clear to everyone). There were a few discussion about adding a NullPointerException, personally I wouldn't care if there was one, but implementing this behaviour with a library is the wrong way imo. This spreads inconsistency over D, some use it others don't, beginners will be confused. Btw. when developing, just start your program always with a debugger (shift+F9 instead of F9 for me, not a big deal), it will halt on a segfault and you can check why there is one.
Re: Stack overflow
If you have a null object you get an Access Violation without _any_ further information. That totally sucks. And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. And yes my program start's first with a debugger but, as i said, you will only get Access Violation and must debug by yourself to find the null object, if you avoid assert's.
Re: Stack overflow
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace rswhi...@googlemail.com wrote: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. It doesn't have to be that way. A debug executable contains all sort of debugging information and a Just In Time debugger can attach and make use of it to show the cause of the access violation. Further, on both windows and various flavours of unix you can get a stack dump, which can be loaded into a debugger and used to locate the access violation. For the JIT case it's all automated on windows if/when you have visual studio installed, as soon as any application crashes a dialog appears and you can attach/debug. For the stack trace case I prefer using WinDbg where you can load the stack trace, point it at the PDB (produced even on a release build) and figure out where it crashed. If you have no PDB you can use a MAP file and the stack offsets to determine the crash location. Alternately, on windows you can call SetUnhandledExceptionFilter() to install a handler to catch any/all unhandled exceptions including access violations etc and then using the EXCEPTION_POINTERS ContextRecord member, walk the stack and produce your own stack trace at the instant the application crashes - I have some code which does this somewhere.. This last idea could automatically be built into exes produced by DMD so they all crash and output a stack trace (perhaps only if built in debug mode) and something similar can surely be done for unix. It's been a while since I did any serious development in D so maybe automatic stack traces already happen for some platforms? And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. It is nice to perform the assert/check once, then know from that point on it cannot be null ever again - saves multiple asserts/checks and makes the code cleaner in terms of having less noise. I think types which cannot be null are useful for that reason. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Stack overflow
Am 22.06.2012 16:55, schrieb Namespace: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object). And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. I hope nobody will share code with Ref!Type, if they do people will relay on it and hey, all will do it, I don't need to check here, would be something different if it was not implemented by any library. And yes my program start's first with a debugger but, as i said, you will only get Access Violation and must debug by yourself to find the null object, if you avoid assert's. I have to debug nothing, as written above gdb sets automatically a breakpoint on a segmentation fault and shows me all the information I need.
Re: Stack overflow
On Friday, June 22, 2012 19:59:48 David wrote: Am 22.06.2012 16:55, schrieb Namespace: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object). Well, he's clearly on Windows if he's seeing an access violation, but regardless, there are plenty of developers who have no clue that you can get any information from a segfault or access violation. Personally, I'd been programming in C/C++ for years before I found out it was possible. And it can be _very_ frustrating to get a segfault when all that tells you is that you're programming is crashing somewhere, somehow. Fortunately, debuggers like gdb make it possible to figure out what happened in great detail (either by examining a core dump or running the program in a debugger), but my guess is that Namespace just doesn't know how to do that or that it's even possible - hence his frustration with not getting any information. - Jonathan M Davis
Re: Stack overflow / recursive expansion with alias this
Hm, doesn't anybody know anything about it?
Re: Stack overflow / recursive expansion with alias this
On 04/23/2012 11:29 PM, Namespace wrote:
I have this code:
...
T _get() {
return this._value;
}
const(T) _get() const {
return this._value;
}
You missed the 'immutable' and 'inout cases.
Just use inout(T) _get() inout { return _value; } instead of the two
declarations you have.
...
And therefore i get the same error, as if i wrote return
NotNull!(Foo)(this); instead of return assumeNotNull(this);, in the
_convert method of NotNull. The Output is Stack overflow. I think
that comes from recursive calls which fills the stack? Is that a bug?
Yes.
Re: Stack overflow / recursive expansion with alias this
You missed the 'immutable' and 'inout cases.
Just use inout(T) _get() inout { return _value; } instead of
the two declarations you have.
Oh, thanks a lot, i'm forgetting this often.
...
And therefore i get the same error, as if i wrote return
NotNull!(Foo)(this); instead of return
assumeNotNull(this);, in the
_convert method of NotNull. The Output is Stack overflow.
I think
that comes from recursive calls which fills the stack? Is that
a bug?
Yes.
Some ideas how i can implement this otherwise? And would the bug
fix come with 2.060?
With this functionality, the NotNull struct would be perfect.
Re: Stack overflow / recursive expansion with alias this
... And therefore i get the same error, as if i wrote return NotNull!(Foo)(this); instead of return assumeNotNull(this);, in the _convert method of NotNull. The Output is Stack overflow. I think that comes from recursive calls which fills the stack? Is that a bug? Yes. I found nothing like that. Is the bug reported?
Re: Stack overflow / recursive expansion with alias this
On 04/24/2012 07:09 PM, Namespace wrote: ... And therefore i get the same error, as if i wrote return NotNull!(Foo)(this); instead of return assumeNotNull(this);, in the _convert method of NotNull. The Output is Stack overflow. I think that comes from recursive calls which fills the stack? Is that a bug? Yes. I found nothing like that. Is the bug reported? I remember reporting a similar issue, but that one seems to have been fixed. Feel free to create a new ticket.
Re: Stack overflow / recursive expansion with alias this
On Tuesday, 24 April 2012 at 19:34:26 UTC, Timon Gehr wrote: On 04/24/2012 07:09 PM, Namespace wrote: ... And therefore i get the same error, as if i wrote return NotNull!(Foo)(this); instead of return assumeNotNull(this);, in the _convert method of NotNull. The Output is Stack overflow. I think that comes from recursive calls which fills the stack? Is that a bug? Yes. I found nothing like that. Is the bug reported? I remember reporting a similar issue, but that one seems to have been fixed. Feel free to create a new ticket. That's what I do now. Thanks a lot for your help.
Re: Stack Overflow error missing
On Friday, October 07, 2011 05:28:39 Andrej Mitrovic wrote:
I'm fairly sure this used to give me a stack overflow error:
void test() {
test();
}
void main() {
test();
}
Now it only returns exit code -1073741819.
Could this be related to how WinXP managers error reporting? It's
possible that I have some error reporting service disabled, but I'll
have to check. Is anyone else getting just the exit code?
On Linux, I'm getting a segmentation fault, the same as I always have gotten
when the stack gets blown. So, this does appear to be a Windows-specific issue.
- Jonathan M Davis
