[DGD] Error with 1.5.5

[Raymond Jennings]

Anyway, do you think it would be helpful to attach an unaltered copy of the
files in question, or at least a gdb stack trace?  It looks like dworkin
had trouble reproducing your crash as originally observed.

On Mon, Jul 17, 2017 at 5:17 PM, Raymond Jennings <shentino at gmail.com>
wrote:

> yeah that's what I meant.  I was wondering if they were omitted/implied in
> the snippet you posted to the list.
>
> On Mon, Jul 17, 2017 at 5:10 PM, Blain <blain20 at gmail.com> wrote:
>
>> Negative.  They are needed and I had them just print the error strong to
>> the console when they were evoked.
>>
>> On Jul 17, 2017 19:04, "Raymond Jennings" <shentino at gmail.com> wrote:
>>
>> > Would I be correct to assume that omitting compile_error and
>> runtime_error
>> > etc from driver.c was also part of the "theoretical code" abbrevation?
>> >
>> > On Mon, Jul 17, 2017 at 4:47 PM, Blain <blain20 at gmail.com> wrote:
>> >
>> > > I'm on my phone, so I just wrote that theoretical code by hand.  I
>> didn't
>> > > mean to leave out the delay arg to call_out.  :)
>> > >
>> > > On Jul 17, 2017 18:46, "Blain" <blain20 at gmail.com> wrote:
>> > >
>> > > > The bug is coming from the existence of an undeclared variable.
>> > > >
>> > > > On Jul 17, 2017 17:34, "Raymond Jennings" <shentino at gmail.com>
>> wrote:
>> > > >
>> > > >> Actually, if your version successfully called "compile_error", but
>> > > >> dworkin's aborted due to it being missing, could you double check
>> and
>> > > make
>> > > >> sure the version of driver.c that you posted is a complete copy of
>> > your
>> > > >> version?
>> > > >>
>> > > >> Dworkin is correct that a call to a non-existant function in the
>> > driver
>> > > >> object is rightly supposed to be a fatal error.
>> > > >>
>> > > >> (see http://shentino.github.io/phantasmal/DGD/Running/DGDCrash.
>> html,
>> > > dgd
>> > > >> list message dated Fri Oct 24 08:07:01 2003)
>> > > >>
>> > > >> However, I did notice that your asserted behavior diverges from
>> > > dworkin's
>> > > >> observations.
>> > > >>
>> > > >> Also, a compile error in the driver's source should prevent the
>> driver
>> > > >> from
>> > > >> being called at all, and IIRC, the attempt to call "compile_error"
>> > would
>> > > >> itself have triggered a driver object compile (iirc, attempts to
>> call
>> > a
>> > > >> driver function automatically compile the driver), which in turn
>> would
>> > > >> trigger a runtime error of "compilation within compilation" which
>> > > >> phantasmal's docs cited as a symptom of an improperly
>> > > installed/configured
>> > > >> kernel library (which contains the driver object).
>> > > >>
>> > > >> Dworkin is correct that call_out as a kfun requires a minimum of
>> two
>> > > >> arguments, the name of the function to be called out and the delay
>> for
>> > > the
>> > > >> call.  Failing to conform to this is a syntax error (and would have
>> > led
>> > > to
>> > > >> the aforementioned compile_error call leading to a reentrant
>> compile).
>> > > >>
>> > > >> I'm a little surprised that your description differs from dworkin,
>> and
>> > > in
>> > > >> theory, unless you've erred in your copypaste, the driver source
>> > itself
>> > > >> should have failed to compile after choking on a call_out based
>> syntax
>> > > >> error, and the compilation of foo.c would in theory not have
>> happened
>> > in
>> > > >> the first place.
>> > > >>
>> > > >> I hope I'm not overthinking this lol.
>> > > >>
>> > > >> But at this point I suspect a botched copypaste to the ml for your
>> > > source
>> > > >> code.  Could you double check?
>> > > >>
>> > > >> On Mon, Jul 17, 2017 at 12:49 AM, Raymond Jennings <
>> > shentino at gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >> > If you *were* able to reproduce a true segfault (and not just an
>> > > >> abort), a
>> > > >> > stack trace would be helpful.
>> > > >> >
>> > > >> > Do make sure it's not due to an infinite recursion though.
>> > > >> >
>> > > >> > On Sun, Jul 16, 2017 at 11:24 PM, Felix A. Croes <
>> felix at dworkin.nl>
>> > > >> wrote:
>> > > >> >
>> > > >> >> Blain <blain20 at gmail.com> wrote:
>> > > >> >>
>> > > >> >> > I triggered a segfault after compile_error and before
>> > runtime_error
>> > > >> are
>> > > >> >> > called in the driver object.  I created a bare bones
>> > implementation
>> > > >> and
>> > > >> >> > determined that the following does bug out.
>> > > >> >> >
>> > > >> >> > [/driver.c]
>> > > >> >> > void initialize() {
>> > > >> >> >   call_out("load_foo");
>> > > >> >> > }
>> > > >> >> >
>> > > >> >> > void load_foo() {
>> > > >> >> >   compile_object("/foo");
>> > > >> >> > }
>> > > >> >> >
>> > > >> >> > [/foo.c]
>> > > >> >> > void foo() {
>> > > >> >> >   test = ({});
>> > > >> >> > }
>> > > >> >> >
>> > > >> >> > Also, /auto.c and /auto.h are empty files.
>> > > >> >> >
>> > > >> >> > With the variable test not being declared in foo.c, DGD
>> > segfaults.
>> > > >> The
>> > > >> >> > error message given to compile_error is "undeclared variable
>> > test".
>> > > >> >>
>> > > >> >> The errormessage I get is "/driver.c, 2: too few arguments for
>> > > function
>> > > >> >> call_out".
>> > > >> >>
>> > > >> >> After fixing that, a fatal error: "missing function in driver
>> > object:
>> > > >> >> compile_error", which does crash DGD, not with a segmentation
>> fault
>> > > >> >> but with an abort call.  That is proper and expected behaviour.
>> > > >> >>
>> > > >> >> Regards,
>> > > >> >> Felix Croes
>> > > >> >> ____________________________________________
>> > > >> >> https://mail.dworkin.nl/mailman/listinfo/dgd
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> ____________________________________________
>> > > >> https://mail.dworkin.nl/mailman/listinfo/dgd
>> > > >
>> > > >
>> > > ____________________________________________
>> > > https://mail.dworkin.nl/mailman/listinfo/dgd
>> > >
>> > ____________________________________________
>> > https://mail.dworkin.nl/mailman/listinfo/dgd
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>
>