Hi,

I found the following bug by testing POV-Ray's behavior on very large or
very small values. If a value has more than 125 characters you'll get an
error message "String to long". That is OK. But in some versions (see
below) 
POV-Ray crashes (see also below) if you try to parse a value with a few
characters less than 126. For Example:

#declare a = 
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345

It also happens when you put this into an #if (0=1) directive.
I found the problem in the following versions marked with yes and didn't
found it in the others: 

  version                              system     found
  V 3.1a.watcom.win32                  (Win98)    Yes
  V 3.1g.watcom.win32                  (Win98)    Yes
  V 3.1g.msdos.wat-cwa                 (Win98)    Yes
  V 3.1g.msdos.wat-cwa                 (DOS)      Yes
  V 3.00.msdos.wat-cwa                 (Win98)    Yes
  V 3.1g.linux.ggc                     (SuSE 6.2) No
  V 3.1g.msvc.win32                    (WIN??)    No
  V 3.1e.msvc.win32                    (Win98)    No
  V unofficial.MegaPOV.0.4.msvc.win32  (Win??)    No  
  
I found it already in an 3.0 Windows version but I don't remember which
one.
Can you try if you can duplicate the crash with your version. I suppose
it happens only with the wat compiles.

-- 

  >>> Manuel Moser  -  mos### [at] gmxde  <<<

Check AniTMT, a free software to create photorealistic animations:
       German: http://www.anitmt.de/  English: http://www.anitmt.org/



--------------------------------------------------------------------
Windows Crash (3.1g.watcom.win32):
The following message is displayed. And after confirming this POV-Ray is
closed.

  Pvengine


  [...]


  in Modul KERNEL32.DLL bei 015f:bff9d709.
  Register:
  EAX=c00300f0 CS=015f EIP=bff9d709 EFLGS=00010212
  EBX=0158ffbc SS=0167 ESP=0150ff7c EBP=01510218
  ECX=00000000 DS=0167 ESI=00000000 FS=50ef
  EDX=bff76859 ES=0167 EDI=bff79050 GS=0000
  Bytes bei CS:EIP:
  53 8b 15 dc 9c fc bf 56 89 4d e4 57 89 4d dc 89 
  Stapelwerte:

Free translation:

  This application is closed due to an illegal action.
  [...]
  PVENGINE caused an error by an illegal page in module KERNEL32.DLL at
[...]

---------------------------------------------------------------------
DOS crash (3.1g.msdos.wat-cwa):
POV-Ray displays this and terminates back to DOS.

  Exception: 0E, Error code: 0004

  EAX=32313039 EBX=83BDF641 ECX=FFFFFFFF EDX=83BDF5A8 ESI=83BDF668
  EDI=383736B2 EBP=00000001 ESP=83BDF5C4 EIP=83B8FCEF EFL=00010246

  CS=018F-7C541000 DS=0197-7C541000 ES=0197-7C541000
  FS=0000-xxxxxxxx GS=019F-xxxxxxxx SS=0197-7C541000

  CR0=00000000 CR2=00000000 CR3=00000000 TR=0000
 
  Info flags=00008018

  Writing CW.ERR file....

  CauseWay error 09 : Unrecoverable exception. Program terminated.

Post a reply to this message

Attachments:
Download 'us-ascii' (5 KB)

In article <390### [at] gmxde> , Manuel Moser <mos### [at] gmxde> 
wrote:

> POV-Ray crashes (see also below) if you try to parse a value with a few
> characters less than 126. For Example:
>
> #declare a =
>
>1234567890123456789012345678901234567890123456789012345678901234567890123456789
>012345678901234
> 5678901234567890123456789012345

I think there are more urgent problems to be taken care of...


       Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I think there are more urgent problems to be taken care of...

... which doesn't mean we don't appreciate this report.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I tried it in my Solaris compile of povray and it didn't complain anything.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> #declare a =  snip fest.......

i think making povray capable of working with such massive numbers would
slow the whole thing down more than i would like, there have to be limits
and not going crazy has to be one.

also i fail to see the use.....

Rick

Post a reply to this message

"Rick [Kitty5]" wrote:
> 
> > #declare a =  snip fest.......
> 
> i think making povray capable of working with such massive numbers would
> slow the whole thing down more than i would like, there have to be limits
> and not going crazy has to be one.
> 
> also i fail to see the use.....
> 
> Rick

If input values exceed the precision of the internal representation,
they should just be trimmed to fit, not crash the program.

A minor bug but still a bug.

PoD.

Post a reply to this message

On Fri, 28 Apr 2000 19:10:36 +0200, Manuel Moser wrote:
>I found the following bug by testing POV-Ray's behavior on very large or
>very small values. If a value has more than 125 characters you'll get an
>error message "String to long". That is OK. But in some versions (see
>below) 
>POV-Ray crashes (see also below) if you try to parse a value with a few
>characters less than 126. For Example:
>
>#declare a = 
>12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
>
>It also happens when you put this into an #if (0=1) directive.
>I found the problem in the following versions marked with yes and didn't
>found it in the others: 
>
[...]
>  
>I found it already in an 3.0 Windows version but I don't remember which
>one.
>Can you try if you can duplicate the crash with your version.

Doesn't crash on Linux (RH 6.1, Povray compiled by myself), Solaris and
HP-UX. Also the code looks ok (Read_Float just copies to string to a
buffer which is correctly terminated and then calls sscanf).

>I suppose it happens only with the wat compiles.

I suspect that this is a bug in Watcom's sscanf implementation. You may
try to compile and run this program, and see if it crashes, too:

#include <stdio.h>

int main(void) {
    double d;
   
sscanf("12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345",
	   "%lf", &d);
    printf("%f\n", d);
    return 0;
}

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

"Peter J. Holzer" wrote:
[...]
> I suspect that this is a bug in Watcom's sscanf implementation. You may
> try to compile and run this program, and see if it crashes, too:
> 
> #include <stdio.h>
> 
> int main(void) {
>     double d;
>     
sscanf("12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345","%lf",
&d);
>     printf("%f\n", d);
>     return 0;
> }

Can somebody try this for me, because I don't have Watcom and, apart
from that, I don't have any experience with compiling C code.

-- 
  >>> Manuel Moser  -  mos### [at] gmxde  <<<

Check AniTMT, a free software to create photorealistic animations:
       German: http://www.anitmt.de/  English: http://www.anitmt.org/

Post a reply to this message

PoD wrote:
> 
> "Rick [Kitty5]" wrote:
> >
> > > #declare a =  snip fest.......
> >
> > i think making povray capable of working with such massive numbers would
> > slow the whole thing down more than i would like, there have to be limits
> > and not going crazy has to be one.
> >
> > also i fail to see the use.....
> >
> > Rick
> 
> If input values exceed the precision of the internal representation,
> they should just be trimmed to fit, not crash the program.
> 
> A minor bug but still a bug.
> 
> PoD.

Of course, there is probably no use for values like these. And you can
also use "1,23456e120". For me, nobody has to fix this bug. I can
live without. But I also think a bug should not crash the program if you
"only" use things which are not forbidden. Otherwise the programmers
could leave the 126 limit out.
And if somebody can fix the bug why not do it?

Post a reply to this message

In article <390EE6B5.4CC317F5@gmx.de> , Manuel Moser <mos### [at] gmxde>
wrote:

> And if somebody can fix the bug why not do it?

Why? Because it is in the compiler libraries, not in POV-Ray! What do you
prefer, the team chasing extreme condition compiler problems 0.00001% of
users may ever notice or getting the real bugs fixed of which there are
still plenty left.
There are certain limits to resources of the POV-Team, it is that simple.
Just keep in mind we in the team do this for free in our spare time, POV-Ray
is not a commercial program.
Of course, if someone wants to fix the Watcom libraries (if they are
available in source code, if not it is simply impossible to fix this bug by
the team!) he or she is welcome to submit this patch to the team.


      Thorsten


This is my own opinion, I do not speak for the team.

Post a reply to this message