[Gambas-devel] To Tobias : about gb.ncurses interface

[tobi]

> > I saw, you have "changed the version" but not already tagged in svn?
> 
> I will tag it in a few days I think. Just fixing some remaining bugs...
> 
> >
> > Please, don't wait for me with that.
> 
> Just ensure that you will be able to keep the Gambas 3.2 gb.ncurses 
> interface in the next versions without changing everything.
> 
> Gambas 3.X must be able to run Gambas 3.Y code as soon as Y < X
> 
> > The differences in the debugger are overwhelming on the new
> > machine (migrated from 32 to 64 bits)... I could recently spot some strange debugging output from
> > gb.ncurses: on my older, slower machine, the limit is far earlier reached than here but I seriously
> > get entire stack frames smashed when *excessively* hitting non-ascii chars on my keyboard - don't
> > ask me why because the only stack buffer I am using in this case, if I see correctly, is written to
> > by the kernel and only used by ncurses. Since there are no concurrent threads, I'm out of ideas so
> > far and consequently must step through the code in greater detail... That's where the new
> > environment comes in - and, of course, the period of big tests at the end of the school year.
> > 64 bit addresses only are really difficult to read if you're not used to ;) I can even hardly read
> > the assembly code here...
> >
> > Sorry for the still unfinished interface, it must wait until 3.3 ;)
> >
> > Regards,
> > Tobi
> >
> 
> Have you used valgrind on your code? It may help...
> 
> -- 
> Benoît Minisini
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
> 

I have tried but when you just said that... Let me outline the situation:
- I have just tried enabling SSP (which if I remember correctly, arch linux gcc does not do per
  default) but I get no corruption reported
- Contrary, I have a screenshot here that shows that the GB structure has its first 13 longs
  overridden with 0x40404040 (from my 32bit machine) and I wonder where those '@' come from!
- Sometimes I can get a resonable backtrace and just this minute I couldn't get anything useful -
  totally scrambled

Isn't the stack one large memory area without holes? I don't know an option to valgrind to get stack
corruption analysed - and stack smash is just an assumption - for me, valgrind only reports
invalid r/w but those cannot occur on the stack, right?
Having SSP enabled, my program shouldn't have crashed with SIGSEGV but via abort() in case of stack
corruption, unless the error is non-trivial... That's interesting and Wednesday the, for me, most
important test will be written, then I'll have some time left.

I better commit your interface suggestions now for 3.2, regardless of the state of this mess?

Regards,
Tobi