[Vm-dev] script to add internal plugins ?

Sat May 13 18:15:41 UTC 2017

Thanks all, I will have a look and have a look this evening.

@Ben : I was using ubuntu 15.10 (64bits) and gcc 5.1 when I got the errors.
@David : it could be caused by the plugin indeed... But these are default
plugins of the squeak vm, and I guess I should have had the problem while
using the profiler on the latest squeak vm but I didn't, hm... I will try
anyway

I upgraded yesterday to ubuntu 16.04 and gcc 5.4. I just tried to build a
pharo image but it failed due to some missing libs (due to the upgrade I
guess).
So I will fix that first and then try out the suggested solutions.

 Sophie

2017-05-13 18:26 GMT+02:00 Ben Coman <btc at openinworld.com>:

>
> On Sun, May 14, 2017 at 12:22 AM, Ben Coman <btc at openinworld.com> wrote:
> > On Sat, May 13, 2017 at 12:00 PM, Eliot Miranda <eliot.miranda at gmail.com>
> 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".
> >
> > You're the fifth newcomer compiling the VM that I've seen bump into
> > this problem.
> > The fix PR has been available since last October...
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/79
> >
> >
> >>>
> >>> (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 best description I found in a quick search is...
> > http://wiki.osdev.org/Stack_Smashing_Protector
> >
> > This implies a canary variable is being overwritten, which implies(??)
> > a legitimate smashed-stack, with the culprit perhaps being some other
> > protection mechanism like address space layout randomisation.
> >
> > Here is a detailed explanation including sample assembly code on the
> > second page.
> > http://www.drdobbs.com/security/anatomy-of-a-stack-smashing-
> attack-and-h/240001832
> >
> >>
> >> 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.
> >
> > @Eliot, could ASLR cause assumptions about this memory layout to be
> violated?
> >
> >
> >
> > It could be related to EBP register "position independent executables"
> > http://forum.world.st/IMPORTANT-GCC-6-generates-position-
> independent-executables-by-default-on-Linux-td4935173.html
> >
> > This article mentions both Stack Smashing and EBP register but I can't
> > exactly tie them together.
> > https://users.ece.cmu.edu/~vsekar/Teaching/Fall16/18487-f16/
> reading/Makowski_2011_Smashing%20the%20Stack%20in%202011.pdf
> >
> > @Sophie,  Could you report your OS and compiler version here? (sorry
> > if you've already done this elsewhere)
>
> Whoops, I meant add a few other links for background rading...
>
> * http://stackoverflow.com/questions/5863252/disabling-stack-
> smashing-protection-in-ubuntu-11-04
> * https://unix.stackexchange.com/questions/46716/is-there-a-
> way-to-deactivate-buffer-overflow-protection-on-my-machine
> * https://askubuntu.com/questions/318315/how-can-i-temporarily
> -disable-aslr-address-space-layout-randomization
> * https://askubuntu.com/questions/318315/how-can-i-temporarily
> -disable-aslr-address-space-layout-randomization
>
>
> >
> > cheers -ben
> >
> >>
> >> I expect further that you can, and should, disable such checking.
> >>
> >> HTH
> >>
> >>
> >>>
> >>>
> >>> I already ran into this error when I first tried to run the VMProfiler
> a few weeks ago. At that time, I was using a built Squeak VM (still
> linux32x86 , cog.spur, itimer).
> >>> Seeing that I got the same problem building both pharo and squeak vm
> (and not having it with vm I haven't actually built), I guess it has
> something to do with my environment.
> >>> I was told it could be caused by a near-full disk, but I still have
> 8Gb+ of free space so, well.
> >>>
> >>> Does somebody have any idea about what could cause this error ? It
> would actually help me narrowing down the possibilities...
> >>> I am using ubuntu 15.10 (old) so I will update it later today and
> check if it solves the problem.
> >>> I will also try to update some libs, just in case.
> >>>
> >>> In the meantime, i will make a PR with the modified plugins files
> anyway, and see if it gets rejected or not.
> >>>
> >>> Sophie
> >>>
> >>>
> >>>
> >>> 2017-05-11 3:18 GMT+02:00 Ben Coman <btc at openinworld.com>:
> >>>>
> >>>>
> >>>> On Thu, May 11, 2017 at 8:08 AM, tim Rowledge <tim at rowledge.org>
> wrote:
> >>>> >
> >>>> >
> >>>> >> On 10-05-2017, at 4:57 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >>>> >>
> >>>> >>
> >>>> >> On Wed, May 10, 2017 at 02:36:20PM -0700, tim Rowledge wrote:
> >>>> >>>
> >>>> >>>
> >>>> >>>> On 10-05-2017, at 1:47 PM, Sophie Kaleba <
> sophie.kaleba at gmail.com> wrote:
> >>>> >>>>
> >>>> >>>> Hi Tim,
> >>>> >>>>
> >>>> >>>> I hadn't thought about that, thanks ! I will make sure not to
> create any duplicate of these plugins
> >>>> >>>
> >>>> >>> I???ve never thought to experiment and see what happens if one
> tried to make both internal and external versions of the same plugin. I???d
> guess that it might not cause any problems in most cases.. hmm, unless on
> some platform you actually have to compile with different flags, and then
> maybe there???d be problems if the internal version were compiled with flag
> A, the ???.o??? file were left around, the external version compile process
> found it, therefore didn???t compile with flag B, thus making something
> fail?
> >>>> >>>
> >>>> >>
> >>>> >> I have not checked in a while, but I am pretty sure that it is
> perfectly
> >>>> >> ok to have both an internally compiled plugin as part of the main
> VM
> >>>> >> executable, and also an externally compiled version of the same
> plugin
> >>>> >> (a loadable module in a file separate from the main VM
> executable). In
> >>>> >> that case, the external plugin should override the internal one.
> >>>> >>
> >>>> >> The idea is that it should be easy to make an external plugin that
> might
> >>>> >> add some new behaviour, and the plugin developer should be able to
> do
> >>>> >> this without waiting for somebody else to distribute a new VM.
> >>>> >>
> >>>> >> If this is not the case, then it certainly /should/ be. Tim,
> weren't
> >>>> >> you one of the people who invented this loadable module stuff in
> the
> >>>> >> first place?
> >>>> >
> >>>> > D’oh, of course you’re right. Oh the joys of aging…
> >>>> >
> >>>> > And what I *should* have said was that I haven’t experimented with
> making internal and external versions within the same build process, given
> faint concerns about the object files maybe confusing the matter if one
> version is built and (incorrect) object files are left for the next version
> make-rule to find.
> >>>> > So er, something like build BlobbyPlugin.c -> BlobbyPlugin.o ->
> link to make vm with internal BlobbyPlugin followed almost immediately by
> build BlobbyPlugin.c -> ooh, already got BlobbyPlugin.o -> make library
> BlobbyPlugin.la
> >>>> > I’m imagining a situation where BlobbyPlugin.o actually ought to
> have been (re)compiled with subtly different flags in order to make a
> correct library. I may be being paranoid. Or maybe the OS is actually out
> to get me...
> >>>>
> >>>> Remember, just because you think you're paranoid doesn't mean they're
> >>>> not watching you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170513/4f3f45cc/attachment.html>