Hi, Christophe, did you check locally if some system test fails (or there is some loading error)? I debugged something similar a while ago, and discovered that the source of the problem is usually a test that fails (or errors) and the monkey/fuel is unable to serialize/materialize the associated stack trace. I tell you why. The monkey uses Fuel to serialize and materialize the stack trace of the tests failures. The problem is that sometimes Fuel fails to serialize/materialize such stack trace and then the monkey's output is a Fuel error instead of the original error. The default way of Fuel to serialize a method is: store it's class name, the selector, and the bytecode's hash. To materialize such method (in a potentially different image), Fuel uses the class name and selector to fetch the method (which might be different from the method serialized), and checks that bytecodes' hash are equal. The FLMethodChanged is signaled here, since it's important that bytecodes match. Going back to this particular error, I imagine this reason for the Fuel error during monkey's validation: the original test failure has a a context in its stack trace that points to the changed method, which "changed bytecodes". What I find strange is that (AFAIK) the monkey configures Fuel to serialize the changed entities in a special way where the original bytecodes are stored and then FLMethodChanged shouldn't happen. I could take a look on monkey (more precisely, on ImageWorker) if this error is reproducible... Cheers, Martin On Wed, Mar 30, 2016 at 4:41 AM, Christophe Demarey < christophe.demarey@inria.fr> wrote:

Le 30 mars 2016 à 09:31, Max Leske <maxleske@gmail.com> a écrit :

On 30 Mar 2016, at 09:10, Christophe Demarey <christophe.demarey@inria.fr> wrote:

Hi,

With case #17889, I get the following validation error: Exception: FLMethodChanged: Materialization error. Method SystemSettingsPersistence class>>#initialize changed its bytecodes. I have no idea what to do with that. Yes, I changed this method and … Does anyone have an idea?

Thanks, Christophe

The validation is materializing the method in the parent image, which means the byte code of that method is being installed. It is often safe to ignore that error, so you could override the #defaultAction of FLMethodChanged in the preload, for instance (e.g. with “self resumeUnchecked: nil).

ok, thanks for the workaround.

What I can’t tell you by heart is why the method is being serialized in the fist place.

If you remember the reason, please share it.

Thanks for your quick answer. Christophe