[Gambas-user] Debugging Gambas (again)
jussi.lahtinen at gmail.com
Wed May 1 00:15:20 CEST 2019
*'Briefly, when I said "generalize the discussion" I also meant
generalizing to any interpreter, not just Gambas.'*
C is not interpreted. And generally speaking modern interpreted languages
do not offer direct memory management and thus they never show sig11,
unless they have bugs. So, again you are wrong.
Point 1 is exactly what I have said to you several times now. And now you
tell it to *me*, like it would be new information. Pathological ego.
However, you still haven't quite internalized what you can now repeat.
Excluding the already mentioned exceptions, sig11 is always bug. No other
I guess when you have studied bit more you will tell me that like it would
On Tue, Apr 30, 2019 at 4:57 PM Cedron Dawg <cedron at exede.net> wrote:
> Briefly, when I said "generalize the discussion" I also meant generalizing
> to any interpreter, not just Gambas. This is pretty clear from the second
> line you quoted me on.
> As for the points:
> 1) Gambas programs (except for the JIT component) aren't executed, they
> are interpreted, they are a data stream. The actual execution (native
> machine code) is the interpreter running. So it is the interpreter that is
> causing the seg faults based on the values in the byte code stream, or
> passing along bad values to system calls/external functions which then can
> seg fault. A seg fault is initiated by the processor, which calls a kernel
> handler, which sends a signal, .....
> Either the interpreter checks and catches bad values before it executes
> them and does a clean, hopefully informative, "error exit" or it doesn't
> check and seg faults. You keep inferring fragile code is an error, I don't
> see it that way. That is not the same as saying that Gambas should not
> have any fragile code, which seems to be such a strong sentiment for you
> that you don't make the distinction and say that is a bug.
> 2) "some sort of internal stack" means a program defined LIFO (Last In
> First Out) storage structure and is not referring to the processor stack
> (ESP/EBP register controlled on x86). Whether it is overflow protected is
> implementation dependent. Tobi's testing of GoSubs vs Calls with 10000
> level deep recursive calls without overflow indicates to me that Gambas has
> overflow protection (and automatic expansion) built into its internal
> process control stacks.
> Returning to the OP's particular situation. I think it is safe to say
> that if the interpreter running the OP's Gambas code seg faults then there
> is either fragile interpreter code or a bug in the interpreter code. If it
> is a bug, of course it should be fixed. If it is a matter of fragility,
> whether to add further parameter validation code (i.e. look for errors) is
> a judgement call in which the answer is likely to be yes.
> My initial assessment of this situation was that it was a case of
> interpreter fragility and invalid OP data. Now, I'm not leaning at all.
> Still curious though.
> ----- Original Message -----
> From: "Jussi Lahtinen" <jussi.lahtinen at gmail.com>
> To: "user" <user at lists.gambas-basic.org>
> Sent: Monday, April 29, 2019 5:46:16 PM
> Subject: Re: [Gambas-user] Debugging Gambas (again)
> Did you even read what I wrote? You got nothing correct.
> Your points;
> 1. In C, not in Gambas. We were talking about Gambas.
> 2. Can happen in C, but the stack protection probably stops the execution
> before that happens... and again, not in Gambas.
> 3. Same as point 1.
> "Suppose the interpreter provides a "SendToRemotePeer" ..."
> Wrong, does not happen in Gambas. Unless of course there is bug in Gambas.
> "Should an interpreter be coded to be robust? A general purpose usage one,
> like Gambas, yep. Should it be absolutely robust? I'm not sure that is even
> theoretical possible."
> I'm not talking about "absolute robustness", I'm talking about fixing bugs
> when we find them. Proper error message tells quite a much more than just
> ----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the User