Jump to page: 1 25  
Page
Thread overview
Stack overflow
Jun 22, 2012
Namespace
Jun 22, 2012
Timon Gehr
Jun 22, 2012
Namespace
Jun 22, 2012
David
Jun 22, 2012
Namespace
Jun 22, 2012
Regan Heath
Jun 22, 2012
David
Jun 22, 2012
Jonathan M Davis
Jun 22, 2012
Namespace
Jun 22, 2012
David
Jun 23, 2012
Namespace
Jun 23, 2012
David
Jun 23, 2012
Namespace
Jun 23, 2012
Namespace
Jun 23, 2012
Namespace
Jun 23, 2012
Jonathan M Davis
Jun 24, 2012
Namespace
Jun 24, 2012
David
Jun 24, 2012
Namespace
Jun 24, 2012
Timon Gehr
Jun 24, 2012
David
Jun 24, 2012
Jonathan M Davis
Jun 24, 2012
Namespace
Jun 24, 2012
Jonathan M Davis
Jun 24, 2012
Namespace
Jun 24, 2012
Jonathan M Davis
Jun 24, 2012
Namespace
Jun 24, 2012
Jonathan M Davis
Jun 24, 2012
Namespace
Jun 25, 2012
Jonathan M Davis
Jun 25, 2012
Namespace
Jun 25, 2012
Jonathan M Davis
Jun 25, 2012
Namespace
Jun 25, 2012
Jonathan M Davis
Jun 25, 2012
Timon Gehr
Jun 25, 2012
Jonathan M Davis
Jun 25, 2012
Namespace
Jun 25, 2012
Timon Gehr
Jun 25, 2012
Namespace
Jun 25, 2012
Timon Gehr
Jun 25, 2012
Namespace
Jun 25, 2012
Namespace
June 22, 2012
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?!
June 22, 2012
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
alex@lycus.org
http://lycus.org
June 22, 2012
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?)
June 22, 2012
> 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.
June 22, 2012
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.
June 22, 2012
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.
June 22, 2012
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace <rswhite4@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/
June 22, 2012
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.
June 22, 2012
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
June 22, 2012
> 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.

« First   ‹ Prev
1 2 3 4 5