|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
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
You may also want to change the following in /pliant/language/declare/struct.c
then recompile, then reinstall Pliant:
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
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.