Hi Dario,
if you look at the end of the PharoDebug.log you will see:
Most recent primitives
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
.......
......
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
doesNotUnderstand:
So you have a recursive doesNotUnderstand: error and the system is running
out of memory. The questions are where and why? You can try and debug
this further by running the VM with --trace=259, e.g.
pharo-vm/pharo --trace=259 my image.image
This will produce lots of output, eventually ending in an endless stream of
doesNotUnderstand:'s. So capture the first few megabytes of output (see
e.g. head(1) ($ man head))
FYI
"traceFlags is a set of flags.
1 => print trace (if something below is selected)
2 => trace sends
4 => trace block activations
8 => trace interpreter primitives
16 => trace events (context switches, GCs, etc)
32 => trace stack overflow
64 => send breakpoint on implicit receiver (Newspeak VM only)
128 => check stack depth on send (simulation only)
256 => trace linked sends "
Alternatively you could use a debugger such as gdb and I can tell you how
to put a breakpoint on doesNotUnderstand:
On Fri, Dec 14, 2018 at 3:42 AM Trussardi Dario Romano <
[email protected]> wrote:
> Some consideration:
>
>
> At 12 December:
>
> I work all day with the image.
>
> at: 19:xx I save the image without any problem.
>
> But after saved the image the system begin
> *unstable.*
>
>
>
>
>
>
>
>
>
>
> *When the mouse go on the windows summary bar ( at the bottom of the Pharo
> window ) the image crash. Some time i can launch - relaunch the same image
> from the PharoLauncher ( the pharo run but was unstable ) at: 19:45 After
> reload the unstable image ( as mentioned above ) i do the save command
> ( saving it on itself ) and the system crash. After this crash ( when i do
> the image save command ), i have not been able to launch the image. I do
> not know the status of this image ( I call this corrupt image ) At 13
> December: A) From pharoLauncher i launch the corrupt image some time,*
> * the shell report the issue, *
>
>
>
>
>
>
>
>
> * but don't create the crash.dmp file. B) After copy the pharoLauncher
> corrupt image into Pharo7.0-64DTRDevErr entry i do this:
> /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744
> /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image
> the shell report: *
>
> *pthread_setschedparam failed: Operation not permitted*
>
> *This VM uses a separate heartbeat thread to update its internal clock*
>
> *and handle events. For best operation, this thread should run at a*
>
> *higher priority, however the VM was unable to change the priority. The*
>
> *effect is that heavily loaded systems may experience some latency*
>
> *issues. If this occurs, please create the appropriate configuration*
>
> *file in /etc/security/limits.d/ as shown below:*
>
>
> *cat <<END | sudo tee /etc/security/limits.d/pharo.conf*
>
> ** hard rtprio 2*
>
> ** soft rtprio 2*
>
> *END*
>
>
> *and report to the pharo mailing list whether this improves behaviour.*
>
>
> *You will need to log out and log back in for the limits to take effect.*
>
> *For more information please see*
>
> *...........r3732#linux*
>
> *Errore di segmentazione (core dump creato)*
>
>
>
>
>
>
> * C) i have a PharoDebug.log but has the size of 16MB. How can I send it
> to you? This is the status of the problematic. Thanks, Dario *
>
--
_,,,^..^,,,_
best, Eliot
