[Aldor-l] Aldor crash

[Pippijn van Steenhoven]

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

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,

-- 
Pippijn van Steenhoven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20080618/2ce9dbfa/attachment.bin