Newbie questions about Pliant

Newbie questions about Pliant

Exception 11 when using debug0, console "" fixes it?

Going from release 80, using 84 or 86 I get
exception 11 errors on some of my demos.
Message posted by mujtaba on 2003/09/17 04:18:46
Moving from release 81, using 84 or 86 I get exception 11 errors on some of my 
demos. It works okay if I use debug1 or debug2. I can also fix it by putting a 
console "" in the code where it generates the error.  Is this a known problem?

Message posted by hubert.tonneau on 2003/09/17 07:20:28
Can you publish a short code that would raise the exception ?
It might be a code generator error.
Are you running Linux (what kernel) or Windows (which Windows) ?


Message posted by mujtaba on 2003/09/17 13:11:40
function mode7 image texture angle cx cy params
 arg Pointer:SDL_Surface image texture
 arg Float angle cx cy
 arg MODE7_PARAMS params

 var Address image_p texture_p
 var Int screen_x screen_y
 var Float distance horizontal_scale
 var Int mask_x := texture:w - 1
 var Int mask_y := texture:h - 1
 var Int mx my offset
 var Float line_dx line_dy
 var Float space_x space_y

 image_p := image:pixels
 texture_p := texture:pixels
 
 #putting a console anywhere or using debug1 or 2 instead works
 console ""
 
 for screen_y 0 (image:h-1)

  distance := (params:space_z * params:scale_y) / (screen_y + params:horizon)
  horizontal_scale := distance / params:scale_x

  line_dx := -1 * (sin angle)* horizontal_scale
  line_dy := (cos angle) * horizontal_scale

  space_x := cx + (distance * (cos angle)) - ((image:w / 2) * line_dx)
  space_y := cy + (distance * (sin angle)) - ((image:h / 2) * line_dy)


  for screen_x 0 (image:w-1)
   mx := ((cast space_x Int)) .and. mask_x
   my := ((cast space_y Int)) .and. mask_y
   offset := my * texture:pitch + mx

   (image_p map uInt8) := (texture_p map uInt8 offset)
   image_p := (image_p translate uInt8 1)

   space_x += line_dx
   space_y += line_dy
Message posted by hubert.tonneau on 2003/09/17 13:18:21
Since you are doing low level programming (poking in the memory),
you may well have a buffer overflow.

Use 'memory_checkup' function at the end of your code in order to test.
Message posted by mujtaba on 2003/09/17 13:36:15
Okay, I'll try it when I get the chance. But why would calling
console or debug1&2 work around this problem? Do they somehow 
affect Pliant's code generation or optimization? 
Message posted by hubert.tonneau on 2003/09/17 14:01:31
> But why would calling console or debug1&2 work around this problem?

If you have a buffer overflow, changing any detail will change the
behaviour because what is next in the memory, so where you overflow
will change.

You may also want to change the following in /pliant/language/declare/struct.c
then recompile, then reinstall Pliant:

#if defined(_LINUX_)
  #define _EXPERIMENTAL_
#endif

to

#if false
  #define _EXPERIMENTAL_
#endif

in order to ask Pliant to use a more conservative code generator.
Message posted by mujtaba on 2003/09/19 04:07:06
I tried calling memory_checkup, but it didn't produce anything useful. 
I used debug 2 as the documentation says to, but there are no obvious
warnings of a buffer overflow. Actually, I'm not even sure what to look for.
I'm not familiar with debuging facilites in Pliant apart from using 
console statements. But console statments make the program work, so it isn't
useful.

I was however able to fix the problem by undefining _EXPERIMENTAL_. 
The more conservative code generation works. I'd still rather get
it to work with the new compiler to get the extra speed. 
Message posted by hubert.tonneau on 2003/09/19 07:48:29
> I was however able to fix the problem by undefining _EXPERIMENTAL_.

So, we have a code generator bug :-(

Can you build something that I could run locally (without SDL interface)
that I could use to track the bug. It would help greatly, because a code
generator bug is something really hard to track.