<div dir="ltr">Hi Sophie,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 8:04 AM, Sophie Kaleba <span dir="ltr"><<a href="mailto:sophie.kaleba@gmail.com" target="_blank">sophie.kaleba@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div><div><div><div><div><div><div><div><div>Update :<br><br></div>I did add the plugins to the file. That was the easy part, it went well.<br><br></div>Then it got trickier when I tried to actually build the (Pharo) VM (build.linux32x86/pharo.cog.<wbr>spur/build.itimerheatbeat) with my brand new plugins :<br></div><br>- at first, I had an error : "can't find PharoV50.sources". <br></div><br></div></div><div>(I cloned the opensmalltalk-vm directory, <br></div><div> ran updateSCCSVersions<br></div><div>and then went in the "build.linux32x86/pharo.cog.<wbr>spur/build.itimerheatbeat" and ran ./mvm -f )<br><br>Manually adding a "sources" directory containing the missing file solved the problem<br>Did I miss something on that part?<br></div><div><br><br></div>-OK, now, the VM is built with this small hack.<br><br></div>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 :<br><br>*** stack smashing detected ***: ./squeak terminated<br>output file stack is full.<br></div></div></div></blockquote><div><br></div><div>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 '<font color="#000000"><span style="font-size:12.800000190734863px">stack smashing detected' in our sources and so expect it is being produced by the C runtime on your version of linux.</span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px">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.</span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px">I expect further that you can, and should, disable such checking.</span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px">HTH</span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>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).<br></div>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. <br><div>I was told it could be caused by a near-full disk, but I still have 8Gb+ of free space so, well.<br></div><br>Does somebody have any idea about what could cause this error ? It would actually help me narrowing down the possibilities...<br><div>I am using ubuntu 15.10 (old) so I will update it later today and check if it solves the problem.<br></div><div>I will also try to update some libs, just in case.<br></div><div><br></div><div>In the meantime, i will make a PR with the modified plugins files anyway, and see if it gets rejected or not.<br><br></div><div>Sophie<br></div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-11 3:18 GMT+02:00 Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
On Thu, May 11, 2017 at 8:08 AM, tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br>
><br>
><br>
>> On 10-05-2017, at 4:57 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
>><br>
>><br>
>> On Wed, May 10, 2017 at 02:36:20PM -0700, tim Rowledge wrote:<br>
>>><br>
>>><br>
>>>> On 10-05-2017, at 1:47 PM, Sophie Kaleba <<a href="mailto:sophie.kaleba@gmail.com" target="_blank">sophie.kaleba@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi Tim,<br>
>>>><br>
>>>> I hadn't thought about that, thanks ! I will make sure not to create any duplicate of these plugins<br>
>>><br>
>>> 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?<br>
>>><br>
>><br>
>> I have not checked in a while, but I am pretty sure that it is perfectly<br>
>> ok to have both an internally compiled plugin as part of the main VM<br>
>> executable, and also an externally compiled version of the same plugin<br>
>> (a loadable module in a file separate from the main VM executable). In<br>
>> that case, the external plugin should override the internal one.<br>
>><br>
>> The idea is that it should be easy to make an external plugin that might<br>
>> add some new behaviour, and the plugin developer should be able to do<br>
>> this without waiting for somebody else to distribute a new VM.<br>
>><br>
>> If this is not the case, then it certainly /should/ be. Tim, weren't<br>
>> you one of the people who invented this loadable module stuff in the<br>
>> first place?<br>
><br>
> D’oh, of course you’re right. Oh the joys of aging…<br>
><br>
> 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.<br>
> 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<br>
> 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...<br>
<br>
</span>Remember, just because you think you're paranoid doesn't mean they're<br>
not watching you.<br>
<br>
HTH  ;)<br>
cheers -ben<br>
</blockquote></div><br></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>