Hi,

I have confirmed that this results in an immediate crash when I use Pico Lisp 2.3.6 or newer on my Mac. However, I'm not sure what I can do further to reveal what causes the memory to be overwritten. Any ideas?

/Jon

On 6/26/09 10:13 AM, Alexander Burger wrote:
Hi all,

now Randall and I made some experiments. I inserted the following code
on top of "gltst.l"

################################################################
(load "@simul/gl/lib.l")
(load "@lib/gcc.l")

(gcc "chk" NIL 'heapCrc)

any heapCrc(any ex __attribute__((unused))) {
   int c, i;
   int crc = 0;
   heap *h = Heaps;
   char *p;

   do {
      p = (char*)h->cells;
      do {
         c = *p;
         for (i = 0; i < 8; ++i) {
            if ((c ^ crc) & 1)
               crc ^= 0x14002;  /* Polynom x**16 + x**15 + x**2 + 1 */
            c >>= 1,  crc >>= 1;
         }
      } while (++p < (char*)(h->cells + CELLS));
   } while (h = h->next);
   printf("%d\n", crc);
   return T;
}

/**/

# Pre-load functions to avoid later heap usage
(mapc getd
   (quote
      glut:Init glut:InitDisplayMode glut:InitWindowSize glut:CreateWindow
      gl:ClearColor gl:MatrixMode gl:LoadIdentity gl:Ortho ) )

(setq Mode (| GLUT_SINGLE GLUT_RGB))

(prog  # Pre-allocate heap
   (heapCrc)
   (glut:Init)
   ...
################################################################

The intention was to repeatedly calculate the CRC sum over the Lisp
heaps (a linked list of malloc'ed memory blocks), to find out if and
when memory is overwritten by one of the graphics functions.

The code defines a 'heapCrc' function which prints the CRC sum, to be
compared to subsequent calls. The pre-loading of ot the 'glut:xxx" and
'gl:xxx' functions, and the constant 'Mode' is necessary because
otherwise the heap would be changed by such side-effects.


Now, the interesting thing is: It crashes immediately! That is, it is
'heapCrc' itself that crashes (is this correct, Randall?). One of the
heap links must be broken, as the CRC calculation does not do anything
dangerous per se.

It is not clear for me if the memory is overwritten by the OpenGL
function, or already by the dlopen/dlsym mechanism when PicoLisp loads
the library. The latter case would mean that other dynamically loaded C
functions (including 'heapCrc') would also corrupt the system.

Perhaps somebody else likes to experiment with this (if time and a Mac
is available)?

Cheers,
- Alex

--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to