v2.5_branch cannot properly recover from aborted oword procedures in external
ngc files.
Symptom: aborted O-word subroutine leaves wrong file as current file, next run
command executes the wrong file.
---> please scroll to bottom to the decision item.
Reproduce by:
- have a ngc files like so
I failed to explain why I tagged this as 'serious'. The reason is: it can lead
to accidential execution of code which should not be executed.
to demonstrate, try the following foo.ngc and go through the steps described.
foo.ngc:
(DEBUG, this shouldnt be executed because it's not part of a
Michael Haberler wrote:
> I failed to explain why I tagged this as 'serious'. The reason is: it can
> lead to accidential execution of code which should not be executed.
>
I don't think you need to explain this to most programmers, the
implications were QUITE
obvious to me. Thanks much for di
The reason USE_LAZY_CLOSE was originally put in the code was so that
after loading a file, it would not be closed until another one was
opened. That way, MDI code could call subroutines in the (still open) file.
I haven't followed how things have changed since I originally
implemented that klud
Ken -
thanks for the explanation. It was unclear from the code what this was for, and
I didnt find it in the docs.
Am 15.09.2011 um 18:51 schrieb Kenneth Lerman:
> The reason USE_LAZY_CLOSE was originally put in the code was so that
> after loading a file, it would not be closed until another
I wonder what folks think about the current EMC behaviour of 'silent
segfaulting'.
IMO this is unacceptable - it should at least report the fact and create a
backtrace for inspection.
Opinions?
-Michael
example - while debugging a patch, the task interp instance segfaulted and
continued to
I just pushed a commit and got an odd series of messages (also, there
was no announcement on #emc-devel)
It does look as if the push got through.
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 541
That's OK with me.
Ken
On 9/15/2011 5:28 PM, Michael Haberler wrote:
> Ken -
>
> thanks for the explanation. It was unclear from the code what this was for,
> and I didnt find it in the docs.
>
> Am 15.09.2011 um 18:51 schrieb Kenneth Lerman:
>
>> The reason USE_LAZY_CLOSE was originally put in
Of course, segfaulting is unacceptable to begin with. It's pretty hard
to eliminate them if no one knows that they occurred. It would be great
if we generated some sort of message with an opportunity to report this
to the developers.
It's hard to do that if a machine isn't connected to a networ
Here is a patch for the aborted o-word sub issue.
I'd propose that for v2.5_branch (the stack unwind code was introduced post
v2.4)
Since it goes to, uhm, private parts of the interpreter I'm asking for review.
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/664d836adbc725004d1cb29ef70f39fa7
Here is a patch to enable calling MDI oword subroutines from MDI when the
Interpreter has no file open.
This also removes the lazy_close code.
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/51ef5f4c6a5ed3d5100f1bc5451a5db04012bfbd
runtests is ok on that and the previous patch applied in any
11 matches
Mail list logo
