octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #64784] VM causes coredump since recent change


From: anonymous
Subject: [Octave-bug-tracker] [bug #64784] VM causes coredump since recent changes
Date: Thu, 19 Oct 2023 22:16:39 -0400 (EDT)

Follow-up Comment #8, bug #64784 (project octave):

I tried the proposed patches (https://savannah.gnu.org/bugs/?64775#comment5),
but the core dump still persists.


 version("-hgid")
ans = bac9c48047cd+


But I think that I found the issue (when trying to condense the code into a
shareable version):

a)
For certain parts of the application, I need to deactivate the VM.

(I use the python bridge pythonic to execute some logic in python code.
Pythonic does not (yet) seem to be compatible with the VM: When the VM is
active, Octave gives a warning and then dies/does not react any longer and the
octave process needs to be killed. „warning: Auto-compilation of pyobject
failed with message Classdef constructors are not supported by the VM yet“)

b) 
I use a code snippet script for logging and execution time monitoring. This
snippet script is then automatically compiled by the VM, but causes then a
warning later in the application parts where the VM is not active:
„warning: Executing compiled scripts in the VM from an un-compiled function
is not supported yet“

c) In order to avoid the warning, I tried to VM clear the snippet code using
VM_Compile(…,“clear“) but within the snippet script itself. This was a
little dodgy, but the snippet itself seemed to be a nice and especially
central place. This then seems to cause the core dump, so obviously the VM is
not yet sufficiently robust in such a case.

d)
I now VM clear the snippet each time when I disable the VM and outside the
snippet and the core dump does not occur any longer. 

e) 
Note that the core dump error message in the application is „Assertion `bsp
+ N_LOCALS() == sp' failed.“).
But in the simplified condensed code, it is just a core dump without this
message. But I also got the above error message in the simplified code when
changing the code a little and as the changes prevent the core dump in the
application, it seems to be have been the issue and I did not investigate
further. 

Snippet_LogStep.m

if VM_Compile
  disp("VM Clear in Snippet_LogStep");
  vm_compile("Snippet_LogStep", "clear");
endif

if (ParseTime && !isempty(ParseStep))
  printf("Step: %35s ( %5.1f s)\n",ParseStep,toc()-t_start);  t_start =
toc();
endif

test2.m

function test2()

  global ParseTime;
  global VM_Compile

  t_start = toc();

  a = 1;
  ParseStep = "test2: Init";
  source Snippet_LogStep.m; # now Snippet_LogStep is VM compiled

  ParseStep = [  "test2 before deactivating the VM : VM is executing "
num2str(__vm_is_executing__()) ];
  source Snippet_LogStep.m;

  # need to deactivate vm as pythonic is not supported by the vm
  if VM_Compile
    vm_enable (0,"local");
  endif

  # call octave functions not yet compatible with the VM

  # activate VM again
  if VM_Compile
    vm_enable (1,"local");
  endif

  ParseStep = [  "test2 after reactivating the VM: VM is executing "
num2str(__vm_is_executing__()) ];
  source Snippet_LogStep.m;

endfunction




global VM_Compile = true;
global ParseTime = true;


if VM_Compile
  vm_enable (1);
endif
tic;
test2();

VM Clear in Snippet_LogStep
Step:                         test2: Init (   0.0 s)
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64784>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]