Bug?

[k6sti]

I take advantage of viewport clipping in a program. I found that I had to limit errant values to LINE avoid a crash. I'm using FB 1.10.1 (32 bit) in Windows 10. I use WINDOW and VIEW, but this simple program crashes.

Brian

Code: Select all

	SCREENRES 800, 600
	DIM a AS DOUBLE
	a = 1E10		' 1E9 does not crash
	LINE (0, 0) - (a, a)
	SLEEP

[dodicat]

If you use ulong, you get a warning.

Code: Select all

Screenres 800, 600
Dim a As Ulong
a = 1E10		' 1E9 does not crash

Print a

Line (0, 0) - (a, a)
Print Point(0),Point(1)
Sleep
 

[k6sti]

The documentation for Line doesn't specify an argument type.

Using Ulong, 2147483600 crashes and 2147483550 does not. This is close to the positive limit of 2147483647 for Long.

Brian

[RetardedAndProud]

Interestingly, negative works...

Code: Select all

	SCREENRES 800, 600
	DIM a AS DOUBLE
	a = 1E-10
	LINE (800, 600) - (a, a)
	SLEEP

[k6sti]

Both Line and Pset want Single arguments according to the assembler code generated by the -RR compiler option.

Brian

[paul doe]

Indeed, but if you dig a bit deeper:

https://github.com/freebasic/fbc/blob/m ... gfx_line.c

They get converted to ints (longs) along the way, so it has no point. Perhaps at some point, they intended for FBGFX to be sub-pixel accurate, and then it never got implemented?

As a side note, the actual usable range is MIN_LONG+65 <--> MAX_LONG-64. Going outside this range causes an overflow (haven't checked why; not gonna dig on this any more deeper)

PS: Indeed, seems like older pages like PUT, PSET, LINE and CIRCLE don't detail the type of the arguments they expect, as newer pages do. Could be a good idea to add that, based on the current code for FBGFX?

[k6sti]

Thanks for the sleuthing, Paul.

I don't think FB should crash for any input value, but perhaps this isn't consistent with other objectives the designers may have. At the least I think the documentation should state the crash-free argument limits for Line and Pset.

This issue isn't a problem for me as I simply limit the argument to some large value that prevents a crash but doesn't affect plotted output.

Example plots here:

Ihttps://k6sti.neocities.org/splot.htm

Brian

[paul doe]

...
I don't think FB should crash for any input value, but perhaps this isn't consistent with other objectives the designers may have. At the least I think the documentation should state the crash-free argument limits for Line and Pset.
...

No problem. It is as you say: apparently, they had other design goals, but somewhere along the road they were changed. There are many places where fbc doesn't sanitize input. The codebase for FBGFX is old and wasn't touched much, hence why some bugs are still being hit. Expecting the docs to detail every 'sane' range for every function would be unreasonable (mostly because, like here, they aren't really known), but having the doc pages (especially older ones) state the type of the arguments they expect is not a bad idea, indeed.

[fxm]

Both Line and Pset want Single arguments according to the assembler code generated by the -RR compiler option.

Yes, such graphic keywords must be compatible with floating point data type for their coordinate arguments, as they can be used in a customized coordinate system.

[k6sti]

Yielding a nonsense response for a wild input is fine. Crashing is something else. I was surprised FB would do that. I can't recall it happening to me before.

The Single input is probably to accommodate the coordinate transformation Window provides. Draw String, also subject to Window, wants Single, too. [The comment from fxm about this just appeared as I was typing this.]

Corrected URL for plot examples:

https://k6sti.neocities.org/splot.htm

Brian

[caseih]

On Linux it gives a floating point exception. This comes out of the FPU itself.

I'm not quite sure what Paul is referring to earlier about the designers maybe changing the requirements along the line. As far as I can tell, there are two parts to gfx-line.c. One is the actual line drawing algorithm itself which deals solely in integer coordinates which makes sense as pixels traditionally aren't divisible. Then there's the fb_GfxLine() routine, which you call with FLOAT coordinates. They indeed can be scaled in arbitrary ways according to the active viewport. I suspect the error is happening in one of these routines (fb_hFixRelative or fb_hTranslateCoord).

This is definitely a bug in the runtime, but it's not necessarily one worth fixing, in my opinion. While the FB runtime could trap the floating point exception and deal with it, it currently does not. Somewhere in the routines I noted above, something bad is happening, but I'm not sure what exactly. It's not an overflow, and it's not a divide by zero, as both of those have their own FPU exception. Would be interesting to build the compiler with full debug symbols in the runtime library and see exactly where the error is occurring.

[k6sti]

On Linux it gives a floating point exception. This comes out of the FPU itself.

Thanks for checking this in Linux. After a wild input to Line in Windows 10, the program window dissolves without any message.

Elsewhere in my program, I use some assembler code to detect a bad result due to FP division by a tiny number in a matrix inversion. I check the result with the fxam instruction after the divide. I don't worry about preventing the divide itself since my program never loses control. FP exceptions seem to be disabled within user code, at least in Windows 10.

I just wanted those who maintain FB to be aware of this issue. I'm happy to let them decide whether it's worth addressing.

Brian

[caseih]

I tried compiling the example with -exx. That shows the graphics window, but I can't press a key to exit the program and the screen is blank. I don't see any error message on the console. I can control-C the window, but the executable itself continues to run. Does not use CPU, so it's not stuck in a loop. Odd stuff.

[fxm]

Referring to the code of the first post of this topic, I get a runtime error message (on the command prompt window) only for fbc 32-bit:

Aborting due to runtime error 11 ("floating point error" signal) in C:\.....\FBIDETEMP.bas::()

Maybe the "floating point error" is only for fbc 32-bit, and there is another code bug after that.

[SARG]

I tried with a low level debugger and I got a division by zero (64bit).

Then I did some tests with differents values.
If both initial X and initial Y are not zero --> no crash.
Depending the values the results are a bit surprising (final X is on left or right even with positive value). excute code below.

Code: Select all

	SCREENRES 800, 600
	DIM a AS DOUBLE
	dim as long lg 
	dim as single sng
	a = 1e10 
	lg=a
	sng=a
	print
	print 
	print "lg=";lg
	print "sng=";sng	
	
	print "a=1E10 only X"
	LINE (200, 40) - (a, 40)
	print
	print
	print "x=";point(0)
	print "y=";point(1)
	print
	print
	LINE (200, 80) - (a, a)
	print
	print "a=1E10 X et Y nothing draw"
	print "x=";point(0)
	print "y=";point(1)
	print
	print