[Aldor-l] Aldor crash

Wed Jun 18 03:50:53 EDT 2008

On 06/18/2008 01:28 AM, Pippijn van Steenhoven wrote:
> Hi,
> 
> today, I updated Aldor to work on Visual Studio 2008 as windows console
> application. It works fine but behaves exactly like the one I built on
> linux regarding crashes. Can anyone confirm that the following sequence
> yields a segmentation fault:
> 
>   $ aldor -gloop
>   Aldor
> 
>   Copyright (c) 1990-2007 Aldor Software Organization Ltd (Aldor.org).
> 
>   Release: Aldor(C) version 1.1.0 for LINUX(glibc-unknown) 
>   Type "#int help" for more details.
>   %1 >> #include "aldor"
>                                              Comp: 40 msec, Interp: 10 msec
>   %2 >> #include "aldorio"
>                                              Comp: 10 msec, Interp: 0 msec
>   %3 >> import from Integer
>                                              Comp: 10 msec, Interp: 0 msec
>   %4 >> 3
>   Program fault (segmentation violation).Program fault (segmentation violation).
>   %4 >> 3
> 
>   #1 (Error) No meaning for identifier `print'.
> 
>   %5 >> 3
>   Segmentation fault

You are doing the wrong thing.

 >aldor -gloop
Aldor

Release: Aldor(C) version 1.1.0 (trunk-23 AXL_EDIT_1_1_13_18=0) for 
LINUX(glibc2.3)
Type "#int help" for more details.
%1 >> #include "aldor"
                                   Comp: 50 msec, Interp: 0 msec
%2 >> #include "aldorinterp"
                                   Comp: 50 msec, Interp: 0 msec
%3 >> import from Integer
                                   Comp: 20 msec, Interp: 0 msec
%4 >> 3
3 @ AldorInteger
                                   Comp: 0 msec, Interp: 140 msec
%5 >>

The sequence of your step shows a bug in Aldor since segfaults should 
never happen, but the right way currently is to replace "aldorio" by 
"aldorinterp".

Look at
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/aldor/include/aldorinterp.as
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/aldor/src/aldor_gloop.as
for more details.

Oooops, https://aquarium.aldor.csd.uwo.ca/svn/trunk is down again.

All that seems to have historical reasons, since the standard library 
was axllib. And this works...

woodpecker:~/scratch>aldor -gloop
Aldor

Release: Aldor(C) version 1.1.0 (trunk-23 AXL_EDIT_1_1_13_18=0) for 
LINUX(glibc2.3)
Type "#int help" for more details.
%1 >> #include "axllib"
                                   Comp: 140 msec, Interp: 10 msec
%2 >> import from Integer
                                   Comp: 30 msec, Interp: 0 msec
%3 >> 3
3 @ Integer
                                   Comp: 0 msec, Interp: 50 msec

The library libaldor does not know of a function "print". But such a 
function is required by "aldor -gloop".

Ralf

> To those who know the compiler internals:
>  - gen0MakeApplyArgs calls gen0AbContextType in order to receive a TForm
>  - gen0AbContextType calls gen0AbType for the TForm to be returned
>  - gen0AbType calls abGetCategory for a TForm to be passed to
>    tfDefineeType the return value of which is to be returned
>  - abGetCategory sets the TForm it will return to tfUnknown
>   - The function goes through several if/else conditions that might set
>     the TForm variable, but none of them apply, the TForm returned is
>     tfUnknown
>  - after tfDefineeType processed the TForm, it is still tfUnknown
>  - back up in the call tree in gen0MakeApplyArgs, the returned TForm is
>    thus tfUnknown
>  - in this function, the TForm is used as argument to tfMapArgc
>   - after initial processing with tfFollow it calls tfFollowArg with our
>     tfUnknown as first argument and 0 as second argument.
>    - tfFollowArg checks whether i (which is 0) < tfArgc (tfUnknown)
>      (which is also 0) and returns NULL if the condition is false. In
>      this case, the condition is indeed false.
>   - Now, with the NULL TForm we got from tfFollowArg, we call
>     tfAsMultiArgc
>    - This function calls tfFollow with the NULL TForm which behaves
>      correctly, skipping any processing if tf == NULL
>    - After that, the tfIsMulti macro is called on the NULL TForm and here
>      is where the code breaks. The macro in turn calls tfTag on the TForm
>      which is defined as (tf)->tag. It dereferences a NULL pointer...
>      boom
> 
> Now, I know this is overly detailed but I thought by doing these
> debugging steps myself, I could lift some work of the people who know
> more about the compiler and motivate them to give it some thought. Maybe
> some of you thinks "oh right, we need to do it like this...". Personally,
> I have little ideas on this. I don't know what TForms really are and I
> don't know how to code is supposed to behave in this case.
> 
> Although I can't imagine it would be helpful to anybody, here is the
> AbSyn that was passed to gen0AbContextType, which returned tfUnknown as
> an answer:
> http://xinutec.org/~pippijn/files/txt/06f39ed2e3b1a89858491d955803e8d3.txt
> 
> I still have a lot to learn about the aldor internals. It is a rather
> large piece of software and I must say, even though I have been fretting
> about its instability, a sublime piece of art. I'm enjoying the read.
> 
> Regards,