hi,

clipka <ano### [at] anonymousorg> wrote:
> Known issue:
>
> User-defined functions may cause a hard crash on some platforms.

I've tried with two scenes, one crashes, the other does not.  the only
difference, afaict, is that the first uses array syntax in both declaration and
in one of the function components, while the second has no array stuff.

> If you encounter this issue, pelase copy
> `source/parser/parser_function_utilities.cpp` from the current master
> branch.
>
> The Windows binaries appear to be unaffected, so I'm not rushing out a
> new version for now.


regards, jr.

Post a reply to this message

Am 13.01.2019 um 17:11 schrieb jr:

> I've tried with two scenes, one crashes, the other does not.  the only
> difference, afaict, is that the first uses array syntax in both declaration and
> in one of the function components, while the second has no array stuff.

Then the recommended workaround probably applies to your system and, by 
extension, presumably Unix systems in general.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 17:11 schrieb jr:
> > I've tried with two scenes, one crashes, the other does not.  the only
> > difference, afaict, is that the first uses array syntax in both declaration and
> > in one of the function components, while the second has no array stuff.
>
> Then the recommended workaround probably applies to your system and, by
> extension, presumably Unix systems in general.

ok.  do you have a 'wget'able url for that file, please?

btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
without cmap {}, irrespective of charset present in global_settings.  does the
above workaround fix that too?


regards, jr.

Post a reply to this message

Am 13.01.2019 um 18:23 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 13.01.2019 um 17:11 schrieb jr:
>>> I've tried with two scenes, one crashes, the other does not.  the only
>>> difference, afaict, is that the first uses array syntax in both declaration and
>>> in one of the function components, while the second has no array stuff.
>>
>> Then the recommended workaround probably applies to your system and, by
>> extension, presumably Unix systems in general.
> 
> ok.  do you have a 'wget'able url for that file, please?

I have no idea what a "'wget'able" URL is, but maybe this one qualifies:

https://raw.githubusercontent.com/POV-Ray/povray/master/source/parser/parser_functions_utilities.cpp


> btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
> without cmap {}, irrespective of charset present in global_settings.  does the
> above workaround fix that too?

I thought you were confirming that v3.8.0-alpha.10011104 fixed your 
issue? Please clarify, and double-check the version you're running.

Those `text` primitive crashes you were observing are totally unrelated 
to the user-defined function crashes.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 18:23 schrieb jr:
> > ok.  do you have a 'wget'able url for that file, please?
> I have no idea what a "'wget'able" URL is, but maybe this one qualifies:

"man 1 wget", or "curl".  command-line tools to fetch stuff.

>
https://raw.githubusercontent.com/POV-Ray/povray/master/source/parser/parser_functions_utilities.cpp

will do nicely.  thanks.

> > btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
> > without cmap {}, irrespective of charset present in global_settings.  does the
> > above workaround fix that too?
>
> I thought you were confirming that v3.8.0-alpha.10011104 fixed your
> issue? Please clarify, and double-check the version you're running.
>
> Those `text` primitive crashes you were observing are totally unrelated
> to the user-defined function crashes.

yes, I appreciate that.

I used a reduced version of the 'pav-patt.pov' for the test, with the latest (ie
10011104) alpha.  it crashes when T2 "visible":

#version 3.8;
global_settings {assumed_gamma 1}

#declare S = "abcdef";

#declare T1 = text {
  ttf "arialbd.ttf" cmap { 1,0 charset 0 }
  S
  0.001 0
  pigment { color rgb<1.0, 0.6, 0.2>*1.25 }
  no_shadow
};

#if (0)
#declare T2 = text {
  ttf "arialbd.ttf"
  S
  0.001 0
  pigment { color rgb 0.1 }
  no_shadow
};
#end


regards, jr.

Post a reply to this message

Am 13.01.2019 um 21:06 schrieb jr:

>> I have no idea what a "'wget'able" URL is, but maybe this one qualifies:
> 
> "man 1 wget", or "curl".  command-line tools to fetch stuff.

Heh, don't expect me to know about any of that; I'm a Windows jockey and 
mouse pusher ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 21:06 schrieb jr:
>
> >> I have no idea what a "'wget'able" URL is, but maybe this one qualifies:
> >
> > "man 1 wget", or "curl".  command-line tools to fetch stuff.
>
> Heh, don't expect me to know about any of that; I'm a Windows jockey and
> mouse pusher ;)

:-)  (or perhaps a frown.  really not sure)

on "the substance" then, you manage to reproduce the crash, I take it?


regards, jr.

Post a reply to this message

Am 13.01.2019 um 22:01 schrieb jr:

>> Heh, don't expect me to know about any of that; I'm a Windows jockey and
>> mouse pusher ;)
> 
> :-)  (or perhaps a frown.  really not sure)
> 
> on "the substance" then, you manage to reproduce the crash, I take it?

More like, "I'll get back to you on that".

That was the status when I wrote that post, anyway. Meanwhile I did find 
a bug that could conceivably cause a crash, and am in the process of 
submitting a fix.

Post a reply to this message

Another known issue:

Scenes making use of `text` primitives may cause a parse error or even 
hard crash under certain circumstances. This time the Windows version 
must also be considered vulnerable.

If you encounter this problem, try inserting `cmap { 1,0 charsert 0 }` 
after the font file name. Alternatively, using `#version 3.7; 
global_setting { charset ascii }` should also be a viable workaround as 
long as you do indeed only use ASCII characters.

Post a reply to this message

Am 13.01.2019 um 23:04 schrieb clipka:
> Another known issue:
> 
> Scenes making use of `text` primitives may cause a parse error or even 
> hard crash under certain circumstances. This time the Windows version 
> must also be considered vulnerable.

Users building their own binaries (most notably Unix users) may also use 
`source/core/shape/truetype.cpp` from the latest master, which should 
fix the issue:

https://raw.githubusercontent.com/POV-Ray/povray/master/source/core/shape/truetype.cpp

Post a reply to this message