forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Voice of doom: Stack overflow in 64bit
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Jul 19, 2019 5:12 pm    Post subject: Voice of doom: Stack overflow in 64bit Reply with quote

Looks like I jinxed to myself few days back when wrote in the other thread that i do not like to see the meaningless for 99.99999% users crash reports. Well, programming devilry clearly reads this forum and first time in history it started giving me unbelievable crash reports like that.
You wanted no binary garbage - you got it. After clicking OK program quietly disappears without a warnings or traces together with the SDBG64. No even info about # of offending line.

How come 64bit program can have stack overflow when it was promised that in 64bits there will be no damn stack anymore (or its limit will automatically adjust without user knowing about stack existence)? Same happens when i debug : i do step by step to the line which should call integer function and at that same moment i get this stack overflow.

This happened when i increased few array variables sizes to 61x61x300 (declared in the source, i.e. non-allocatable). These small arrays are nothing compared to the total memory. There exist other allocatable arrays MUCH larger in size than these, grabbing almost entire memory of PC. Decreasing their size has no effect on stack overflow. Now i can not even load functions containing these smaller arrays -- immediately getting stack overflow and crash.

And later that day true miracles started. I returned back to older arrays but this did not help and other problems started to appear. Inside DO loops execution of code started jumping over multiple lines as if they do not exist. This can be even recorded on movie because is reproducible in debugger...Is today a saturday when this devilry usually danced full force on my dead code ? Smile)) But i have never seen such crazy behavior before. Developers have take a note, that if their compiler will work OK on my codes, it will work on most of others. Have to stop. Will check later if this is the code, or computer or compiler got corrupted. Reboot of computer like in the times of old FTN77 did not help...And always there is some chance that processor hits the memory addressable limit...Fun is that after increasing array sizes code started working ok. Hell knows what's going on with these bewitched computers.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sat Jul 20, 2019 7:47 am    Post subject: Reply with quote

Dan

There is nothing for me to work with here.

Who made the promise and where? Where is the means of reproducing your failure?
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Jul 20, 2019 11:17 am    Post subject: Reply with quote

Paul,

It’s a Cri de Coeur, a cry of exasperation or maybe desperation rather than for immediate help. Desperate Dan* knows you have to beware what you wish for, although whether or not he knows where the meme lies in the Aarne-Thompson-Uther Index is another matter. Note that Dan’s recourse to the language of Folklore in his final paragraph could be classified under several headings in the A.T.U index!

If Fairy Tales don’t appeal, then there is always The Monkey’s Paw.

The real point that worries me is the semi-religious belief that 64 bit-ness is the answer to everything, when clearly it is not, in the way that .NET isn’t, and ‘modern Fortran’ isn’t either.

Since a stack overflow occurs when you reach the end (and try to pass it) of a data structure, then you need to be careful as you approach it. It’s like walking towards the edge of a precipice: method 1 is don’t go near, method 2 is to wear a safety harness. In Fortran, method 1 is probably to avoid the use of local variables that take up much stack space. Method 2 might be to have a function that tells the program how much stack space is used or left at any time – perhaps graphed in real time.

I’d be prepared to bet that the problem occurred when Dan edited something with a ’replace all’ and something unintended was replaced. (And it stayed altered when the smaller array extents were re-applied). Such a thing happened to me while experimenting with colours for a logo and changed all RGB@ parameters from (0,255,255) to something else lighter, and all of a sudden my grid lines became less visible – I’d forgotten since 2005 that they were that particular colour. Dan should revert to a backup, and all will be fine and Dandy.

Eddie

*When the problem is resolved, I suggest dining on Aunt Aggie’s Cow Pie**!
**British meaning.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Jul 21, 2019 5:42 am    Post subject: Reply with quote

Eddie, you got me 99.9999% right. I had bad day yesterday, like no other one, no new things worked plus all reliable old things broke. Not beliving my eyes i had to reverse to backups almost one month old. Now i suspect something wrong could be in OpenGL. Because it influenced the appearance of Stack overflow error

The only tiny bit where you were wrong is how to take care of stack. You know well i am furious at its hiccups in previous 32bit compiler and hoped in 64bits it will not be needed. Why the heck this stack still exists in 64bits? This is utter rudiment of poor older times a la "640k will be enough for everyone" but actually this was not enough for anything (today we have 100,000 times more). Default restriction on 100 or 200 MB in 32 bit FTN95 caused a lot of headache. Changing it was not always working reliably. Now with 64bits we can get 10-100 times more RAM why the heck to keep stupid stack low? Is there at least one reason to have word "stack" not being exterminated from the vocabulary?


Last edited by DanRRight on Sun Jul 21, 2019 4:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sun Jul 21, 2019 10:27 am    Post subject: Reply with quote

Dan

64 bit FTN95 is not a new compiler it only has a new "backend". If the concept of using a stack is old hat (which I doubt) then we have to live it.

However, it may be possible to get the linker to increase the default stack size depending on the amount of RAM available.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Jul 21, 2019 4:49 pm    Post subject: Reply with quote

Just the way stack is set in 32bit can scare anyone. To setup 12GB stack limit for example you now have to count zeros till you are lost.

/stack:12000000000

I for example ones miscalculated zeros and was out of luck for several weeks pulling my last hairs while trying to find not crashing variants. Please change that for megabytes of least, it was set in bytes a decade before Bill Gates' quote Smile

But better after clicking on OK on that Error Message above would be to receive this, Paul
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Jul 22, 2019 7:29 am    Post subject: Reply with quote

So this is all just a joke. I confess that you had me puzzled by the first dialog which I now assume you created yourself.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jul 22, 2019 3:55 pm    Post subject: Reply with quote

I'd love to be kidding like this but the original dialog was real. And yes, kidding too, because can not blame compiler for that crash - need to check first if this is not due to hitting 64bit limit of the processor. Damn Intel to sell more chips makes limits on processors gazillion times less than formally 64bit OS allows. To be exact, 64bits allow 4 billion times the 32bit limit which as we well remember was 4GB while Intel gave just ~10x more. So i see sometimes i can not load programs, or browsers, and even sometimes graphics driver aborts to 640x480 (but good it does not crash the computer - they amicably solved the problem of crashes). Now need to buy new processor, new mobo, more RAM...
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Jul 22, 2019 8:25 pm    Post subject: Reply with quote

Is this an ftn95 message dialogue or a micro$oft one ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jul 22, 2019 10:46 pm    Post subject: Reply with quote

I thought it's FTN95 64bit. I have another screenshot i saved - may be Silerfrost will tell exactly if this is theirs or Microsoft. Will post it later if i have not lost it
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Tue Jul 23, 2019 5:22 pm    Post subject: Reply with quote

My best guess is that the first dialog is generated by OpenGL.

There is probably an OpenGL error function that could be used by ClearWin+ to provide a trace back. If anyone has the details then please let me know.

Dan: I know that you don't approve of trace backs but they are a great help to those who can tolerate them. In this context there is certainly nothing else that we can do to help.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Jul 23, 2019 9:39 pm    Post subject: Reply with quote

Here is the screenshot continuation of unusual stack overflow. Could be OpenGL related, it recently behaved unusually few times.

Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Wed Jul 24, 2019 7:38 am    Post subject: Reply with quote

The extra information makes a big difference. This looks like a call to the API MessageBox function followed by a call to a ClearWin+ function that raises the exception. This is how ClearWin+ reacts to a user or system error reported by OpenGL so it looks like the error report is generated by the OpenGL library.
Back to top
View user's profile Send private message AIM Address
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Wed Jul 24, 2019 8:21 am    Post subject: Reply with quote

Stack overflows are difficult for the debugger (or any tool). Firstly it means there are megabytes of 'stuff' on the stack. That stuff could be stack frames from recursion gone mad or arrays or anything. The exception will happen mid way through more stack being used so it is very difficult to tell what is valid and what isn't.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Thu Jul 25, 2019 8:42 am    Post subject: Reply with quote

Here is an quote from the help for SLINK64.

Quote:
SLINK64 can use "stack" as an alternative to "stack_size". "stack" takes a decimal value that is the required size in (decimal) megabytes (i.e. millions).


Further information is located at x64 Platform->Further information about 64 bit FTN95.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group