[Vm-dev] script to add internal plugins ?

[David T. Lewis]

On Fri, May 12, 2017 at 09:00:08PM -0700, Eliot Miranda wrote:
>  
> Hi Sophie,
> 
> On Thu, May 11, 2017 at 8:04 AM, Sophie Kaleba <sophie.kaleba at gmail.com>
> wrote:
> 
> >
> > Update :
> >
> > I did add the plugins to the file. That was the easy part, it went well.
> >
> > Then it got trickier when I tried to actually build the (Pharo) VM
> > (build.linux32x86/pharo.cog.spur/build.itimerheatbeat) with my brand new
> > plugins :
> >
> > - at first, I had an error : "can't find PharoV50.sources".
> >
> > (I cloned the opensmalltalk-vm directory,
> >  ran updateSCCSVersions
> > and then went in the "build.linux32x86/pharo.cog.spur/build.itimerheatbeat"
> > and ran ./mvm -f )
> >
> > Manually adding a "sources" directory containing the missing file solved
> > the problem
> > Did I miss something on that part?
> >
> >
> > -OK, now, the VM is built with this small hack.
> >
> > When I try to use the VMProfiler (which works fine using the latest squeak
> > VM from bintray), I get a segmentation fault, with this message :
> >
> > *** stack smashing detected ***: ./squeak terminated
> > output file stack is full.
> >
> 
> I wonder if this is some checking feature supported by the C compiler
> you're using.  I expect that it is either disabled or not available in the
> VMs built on binary.  I say this because there is no occurrence of the
> string 'stack smashing detected' in our sources and so expect it is being
> produced by the C runtime on your version of linux.
> 
> The stack organization in the VM is a little unusual.  The VM reserves
> space for a set of "stack pages" upon which Smalltalk activations exist.
> The space for the stack pages is allocated via alloca on the C stack at
> startup.  It could be that this strange organization, which means that at
> some times, when the VM is executing C, the stack pointer is at the bottom
> end of the C stack, but when it is executing JITted Smalltalk code the
> stack pointer is somewhere in the middle of the C stack.  I expect that the
> C runtime sees this happening and misinterprets it as an error.
> 
> I expect further that you can, and should, disable such checking.
> 


It seems likely that this is a real stack overflow error.

The "stack smashing detected" message comes from the C runtime. I googled it
and found several good explanations.

Here is a tip on how to partially disable the checking (although I do not
think it will help much in this case);

  https://reverseengineering.stackexchange.com/questions/11777/how-to-effectively-bypass-gcc-stack-smashing-detection

The other error message "output file stack is full" comes from the VM itself,
in the pushOutputFile() function in platforms/Cross/vm/sqVirtualMachine.c.

I cannot guess what might be the cause of this, but for purposes of debugging
it might help to try building the VM without the new plugins. If the problem
goes away, then it may indicate a problem in the plugins that are being added.

Dave