[Vm-dev] [OSX] SegFault when executing an image relative location without directory

[tesonep at gmail.com]

Hi Eliot,
   thanks for the fast reply, I can confirm that the error is now fixed.

Thanks!

On Mon, Dec 3, 2018 at 7:50 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Pablo,
> On Mon, Dec 3, 2018 at 10:30 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> Hi Pablo,
>>
>>    fixed; see commit c79879b4b4bd5991bb2a9e7142286c75906700d5
>>
>
> Ugh.  There were a few loose ends :-)  See
> commit 0e962c5f37f639bee6c313bcc630a8cc5902273e
>
> On Mon, Dec 3, 2018 at 2:10 AM tesonep at gmail.com <tesonep at gmail.com>
>> wrote:
>>
>>>
>>> Good morning,
>>>     I have seen that the latest version of the VM (at least the one
>>> build from the commit 649f3f16fc4ca9ce48d069a44aa79ea5d34d821a) presents a
>>> segmentation fault error when it is executed with a relative path to an
>>> image that does not contain directory.
>>>
>>> Ex:
>>>
>>> ./Pharo Pharo.image
>>>
>>> I have detected that the problem is with the implementation of the
>>> Security Plugin. I have seen that ioInitSecurity(void)
>>> of platforms/iOS/plugins/SecurityPlugin/sqUnixSecurity.c assumes that the
>>> path in the static variable imageFile has always a directory.
>>>
>>> As it is looking for the position of '/'
>>>
>>> sqInt ioInitSecurity(void)
>>> {
>>>   int imagePathLen= strrchr(imageName, '/') - imageName;
>>>   char *squeakUserDirectory= 0;
>>>
>>>   /* establish the secure user directory */
>>>   strncpy(secureUserDirectory, imageName, imagePathLen);
>>>   strcpy(secureUserDirectory + imagePathLen, "/secure");
>>> ...
>>>
>>> As you can see this position is never found, and the return of
>>> strrchr is NULL, so the imagePathLen have a negative invalid value if the
>>> imageName does not contain a '/' character.
>>>
>>> Also, I have seen that the existing version of the plugin has been
>>> replaced with the unix version. However, the OSX application that read the
>>> value of the parameters and initializes this static variable has not been
>>> updated to resolve the full path.
>>> I have checked the version of the commit d8934ff and it works perfect
>>> with the previous version of the plugin.
>>>
>>> I am not sure if the solution is to revert the plugin to the original
>>> state or to update the parsing of the parameters to resolve the relative
>>> path to a full path. I will like to have more information about the
>>> original intention of the change.
>>>
>>> Cheers,
>>> Pablo
>>>
>>> --
>>> Pablo Tesone.
>>> tesonep at gmail.com
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


-- 
Pablo Tesone.
tesonep at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181203/e073a8e8/attachment-0001.html>