View mode: basic / threaded / horizontal-split · Log in · Help
June 22, 2012
Stack overflow
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
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
alex@lycus.org
http://lycus.org
June 22, 2012
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?)
June 22, 2012
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.
June 22, 2012
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.
June 22, 2012
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.
June 22, 2012
Re: Stack overflow
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
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.
June 22, 2012
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
June 22, 2012
Re: Stack overflow
> 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
Top | Discussion index | About this forum | D home