Yeh, to be more precise,��

* the problem is that the image somehow got it's display size modified to a very small one.��

* And that happenned while building an image in the CI in headless mode.��

* If the same image is built locally in a vm launched in non-headless mode, the issue cannot be reproduced.

So my conjecture is that

- either the image is changing the display size while loading pillar (less likely and not reproduceable locally)

- either the latest stable VM messes the display size in the image header when running on headless (this is yet to reproduce)

On Sun, Mar 12, 2017 at 10:52 AM, stepharong <stepharong@free.fr> wrote:

guillermo was suspecting a problem with the interpretatin of the image metadata

Maybe related?
http://forum.world.st/BUG-A-problem-with-callbacks-that-shows-up-in-64bits-but-is-on-32bits-too-td4938152.html

On Sat, Mar 11, 2017 at 2:22 AM, Cyril Ferlicot
<cyril.ferlicot@gmail.com> wrote:

On ven. 10 mars 2017 at 18:42, stepharong <stepharong@free.fr> wrote:

We found the problem with Guillermo and this may be a problem of the last
VM.

The image got its starting window size really small: some pixels on some
pixles.
So may be the metadata of the image are systematically corrupted.

Hi

I have a jenkins that produce an image that does not start
when I try to open it locally.

Now if I take the image and load the "same" configuration I get a working
image

I have not idea how to debug that.

Stef

--
Using Opera's mail client: http://www.opera.com/mail/

If it can help: here is the build:

https://ci.inria.fr/pharo-contribution/job/OOnoz/

It is happening in almost all Pharo 6 builds
--
Cheers
Cyril Ferlicot

--
Using Opera's mail client: http://www.opera.com/mail/