POV-Ray : Newsgroups : povray.beta-test : Spline causing 3.8 beta 2 to crash Server Time
23 May 2024 00:04:27 EDT (-0400)
  Spline causing 3.8 beta 2 to crash (Message 13 to 22 of 22)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 10 Feb 2023 11:34:32
Message: <63e67218$1@news.povray.org>
On 2/9/23 07:39, William F Pokorny wrote:
> What I suspect off the top of my head is more recent parser code is 
> dumping the macro defined #local spline where it should not. The first 
> question is why and have a thought or two(a).
> 
> (a) For example, wondering about the new macro caching mechanism and 
> whether it makes the macro 'look' like it's in another ram file with 
> respect to #local ID / spline content persistence.

True to form, my first guesses as to the problem were mostly wrong. :-)

The v3.7 code was aware the #local spine ID might go out of macro or 
file scope. The code did extra work using the old style C++ object 
reference counting and, if need be, local copies of the spline. This why 
v3.7 works for the originally posted code.

At some point after v3.7 the the Parse_Spline() code was substantially 
re-written for reasons about which I'm unsure(a), but in part it 
eliminated the reference counting bits which protected against premature 
deletions of objects by the parser on scope changes.

The code appeared to me to have other issues too. I've attached an 
updated Parse_Spline() which in v3.8/v4.0 is found in:

source/parser/parser_expressions.cpp

The updated code works for all my povr branch spline testing. It will 
likely fix any v3.8/v4.0 code too, but I've not tested that claim.

Bill P.


(a) The newer code allows some interesting things like:

#declare A1=spline {
    cubic_spline
    -0.5, < 1,-1, 0>
     0.0, < 1, 0, 0>
     0.5, < 2, 1, 0>
     1.0, < 1, 2, 0>
     1.5, < 1, 3, 0>
}
#declare A2=spline {A1 linear_spline}
#declare A3=spline {A1 natural_spline
         2.0, < 1, 4, 0>
         2.5, < 2, 4, 0>
         3.0, < 2, 2, 0>
}


Post a reply to this message


Attachments:
Download 'parse_spline_update.cpp.txt' (4 KB)

From: jr
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 12 Feb 2023 10:00:00
Message: <web.63e8febcdd6df1a988a828ca6cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> The updated code works for all my povr branch spline testing. It will
> likely fix any v3.8/v4.0 code too, but I've not tested that claim.

will there be an updated 'povr' in the near future ?  (it's been a while)

will try and patch beta.2 with the update, in the coming days, for testing.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 12 Feb 2023 18:43:04
Message: <63e97988$1@news.povray.org>
On 2/12/23 09:59, jr wrote:
> will there be an updated 'povr' in the near future ?  (it's been a while)
> 

Honest answer is I don't know. Almost exactly a year ago I was pushing 
for one and then - stuff. Lately been starting to play with things again.

However, after my Ubuntu 22.04 upgrade I've still got development issues 
to sort. :-( Some of it is me just not staying current due the long 
break from heavy coding.

The Ubuntu segfault core files are now all in one directory uniquely 
named, for example. It took me an embarrassing amount of time to realize 
that not getting core files wasn't do any of the usual issues, but 
simply that they were not located or named as they always had been. I 
could write (rant) more on the topic, but...

The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch 
and polish to get things going at all. My guess is they'd not taken code 
developers very much into account while testing. Developer related stuff 
seemed to be the source of many issues.

My current fight is with autotools as upgraded. I cannot re-generate a 
configure script cleanly - even with unchanged source! There are 
multiple problems and the first ones looked at aren't making much sense 
to me after spending a big chunk of time on it today. I'll probably next 
try completely uninstalling / reinstalling - fingers and toes crossed. 


To do the debugging I did for this thread I had to dig up an old 
configure file for the same source. The old one from July of last year 
still worked.

It's frustrating to be dealing mostly with the development environment 
and I find myself not wanting to fight through it. But, I'll have to 
grind it out, if I want to put together and ship a povr update. We'll see.

Aside: There's also a list of little things different and annoying in 
22.04 too that I'm just living with at the moment.

> will try and patch beta.2 with the update, in the coming days, for testing.

Thanks! I'm interested in whether the fix works for v3.8b2

As you know, Christoph backed up the parser from the one I branched povr 
off for the v3.8 release. In other words, I know the parser itself is 
different than what is in povr and v4.0/master, but hopefully not in a 
way which too much changed the spline parsing...

Bill P.


Post a reply to this message

From: Cousin Ricky
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 13 Feb 2023 08:36:26
Message: <63ea3cda$1@news.povray.org>
On 2023-02-12 19:43 (-4), William F Pokorny wrote:
> 
> The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch
> and polish to get things going at all. My guess is they'd not taken code
> developers very much into account while testing. Developer related stuff
> seemed to be the source of many issues.

My last few upgrades of openSUSE have seen more and more developer tools
removed from the basic OS.  The excuse I heard was "security," but I'm
starting to wonder if the overlords are seeing themselves as gate keepers.

> As you know, Christoph backed up the parser from the one I branched povr
> off for the v3.8 release. In other words, I know the parser itself is
> different than what is in povr and v4.0/master, but hopefully not in a
> way which too much changed the spline parsing...

For what it's worth, these were my results with openSUSE Leap 15.3:

  povray-3.8.0-alpha.9945627   std::bad_alloc
  povray-3.8.0-beta.1          std::bad_alloc
  povray-3.8.0-beta.2          segmentation fault
  povray-3.8.0-alpha.10013324  std::bad_alloc
  povray-3.8.0-alpha.10064268  std::bad_alloc

I believe alpha.9945627 was the rollback point.


Post a reply to this message

From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 13 Feb 2023 11:30:18
Message: <63ea659a$1@news.povray.org>
On 2/13/23 08:36, Cousin Ricky wrote:
> On 2023-02-12 19:43 (-4), William F Pokorny wrote:
>>
>> The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch
>> and polish to get things going at all. My guess is they'd not taken code
>> developers very much into account while testing. Developer related stuff
>> seemed to be the source of many issues.
> 
> My last few upgrades of openSUSE have seen more and more developer tools
> removed from the basic OS.  The excuse I heard was "security," but I'm
> starting to wonder if the overlords are seeing themselves as gate keepers.
> 
>> As you know, Christoph backed up the parser from the one I branched povr
>> off for the v3.8 release. In other words, I know the parser itself is
>> different than what is in povr and v4.0/master, but hopefully not in a
>> way which too much changed the spline parsing...
> 
> For what it's worth, these were my results with openSUSE Leap 15.3:
> 
>    povray-3.8.0-alpha.9945627   std::bad_alloc
>    povray-3.8.0-beta.1          std::bad_alloc
>    povray-3.8.0-beta.2          segmentation fault
>    povray-3.8.0-alpha.10013324  std::bad_alloc
>    povray-3.8.0-alpha.10064268  std::bad_alloc
> 
> I believe alpha.9945627 was the rollback point.
> 

Thanks and this must mean the fix for Ingo's issue was done by Christoph 
between v3.8 beta1 and beta2.

On recent linux distributions I get that those supporting them want to 
simplify their jobs and the less you ship officially the simpler it is.

With Ubuntu I 'suspect' some of what's happening are changes due its 
broadening adoption - as the windows linux subsystem, for example. I'd 
make a small bet the change in core file handling was done in part to 
better support such uses. The old core handling has issues too.

One of my other pet peeves with Ubuntu 22.04 is they've adopted snaps 
(code on VMs) as the up front supported code for shipped packages like 
firefox. OK, except, I have long run firefox against files located all 
over my computer's file system - especially off ram disks - and by 
default most such file systems are not accessible from within the snap 
instances.

Anyhow. Change. I believe too a younger generation is coming to the fore 
support wise. They see things differently. Most of us old time unix / 
linux users are getting on in years. :-)

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 13 Feb 2023 12:07:40
Message: <63ea6e5c$1@news.povray.org>
On 2/12/23 18:43, William F Pokorny wrote:
> My current fight is with autotools as upgraded. I cannot re-generate a 
> configure script cleanly - even with unchanged source! There are 
> multiple problems and the first ones looked at aren't making much sense 
> to me after spending a big chunk of time on it today. I'll probably next 
> try completely uninstalling / reinstalling - fingers and toes crossed.

OK. Spent another day or so banging away and I can now create updated 
configure scripts which work.

For the record...

- A chunk of the issues had to do with local M4 files in need of update 
due autotool changes.

- One update looks to be a change in the internals of the Ubuntu 22.04 
autoconf code tightening up on something previously allowed with an 
internal M4 macro - which probably should not have been. This tripped up 
one of the M4 macros I re-wrote for the dual (v1.2/v2.0) Simple Direct 
media Layer version support.

- The last autotools issue is another change internal to autoconf, which 
at the moment, I believe a mistake. On generation of configure there is 
some checking done on whether an automake and libtool script called 
'missing' runs. The previous generated code looked like:

---

# Expand $ac_aux_dir to an absolute path.
am_aux_dir=`cd "$ac_aux_dir" && pwd`

if test x"${MISSING+set}" != xset; then
   case $am_aux_dir in
   *\ * | *\	*)
     MISSING="\${SHELL} \"\"$am_aux_dir\"/missing\"" ;;
   *)
     MISSING="\${SHELL} \"$am_aux_dir\"/missing" ;;
   esac
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
   am_missing_run="$MISSING "
else
   am_missing_run=
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' script is 
too old or missing" >&5
$as_echo "$as_me: WARNING: 'missing' script is too old or missing" >&2;}
fi

---

The new failing code looks like:

    # Expand $ac_aux_dir to an absolute path.
am_aux_dir=`cd "$ac_aux_dir" && pwd`

   if test x"${MISSING+set}" != xset; then
   MISSING="\${SHELL} '\"$am_aux_dir\"/missing'"
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
   am_missing_run="$MISSING "
else
   am_missing_run=
   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' 
script is too old or missing" >&5
printf "%s\n" "$as_me: WARNING: 'missing' script is too old or missing" 
 >&2;}
fi

However, the eval "$MISSING --is-lightweight"; now always fails and 
am_missing_run gets set to null / nothing. We get a warning over an 
error as it is not a problem unless some autotools program later needed 
is truly missing. This won't usually happen - excepting maybe in 
corrupted autotools packages or disk failures and such.

Aside: I think someone noticed that case always selected only one of the 
MISSING forms, but when things got hard coded they set up a MISSING var 
which doesn't run! If I hard code the one previously always picked or 
change the code to look as it previously did, MISSING runs and the 
am_missing_run variable gets set up correctly. In the near term guess 
I'm stuck patching the generated configuration file(a) or letting the 
issue go. For the latter, users will, with a few exceptions, see an ugly 
warning message, but things will work.

There were also some necessary autoconf am updates and source code 
updates to hush a new BOOST warning on generic bind variables in the 
global name space(a). This warning doesn't prevent compilation, but it 
makes povr's clean output look ugly.

Bill P.

(a) - The bind methods available in newer c++ versions can perhaps 
replace the BOOST bind code, but I've not gotten around to attempting it.


Post a reply to this message

From: ingo
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 13 Feb 2023 12:25:00
Message: <web.63ea7212dd6df1a917bac71e8ffb8ce3@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> Anyhow. Change. I believe too a younger generation is coming to the fore
> support wise. They see things differently. Most of us old time unix /
> linux users are getting on in years. :-)
>

Try FreeBSD? Much more stable in this regards (and in others probably too)

ingo


Post a reply to this message

From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 13 Feb 2023 13:22:12
Message: <63ea7fd4$1@news.povray.org>
On 2/13/23 12:23, ingo wrote:
> Try FreeBSD? Much more stable in this regards (and in others probably too)

I've toyed with the idea of playing with other linux distributions, but 
not too seriously.

My povr branch is a unix/linux/osx only branch. The only way for windows 
users to play with it is the windows' linux subsystem - which is derived 
from Ubuntu. Ubuntu is also available and supported for the Raspberry Pi 
hardware.

Never say never, but yeah.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 14 Feb 2023 03:35:00
Message: <web.63eb46dedd6df1a988a828ca6cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Thanks! I'm interested in whether the fix works for v3.8b2

need to get back to you in a few days, but quick look-see last night resulted in
"error: 'CurrentTokenDataPtr' was not declared in this scope".  (looks like the
code bases have diverged.. ;-))

re Ubuntu.  Debian now packs all /bin/ in /usr/bin/, and makes the former a
symlink; more Windows mid nineties than Linux :-(.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Spline causing 3.8 beta 2 to crash
Date: 14 Feb 2023 05:06:51
Message: <63eb5d3b$1@news.povray.org>
On 2/14/23 03:31, jr wrote:
> need to get back to you in a few days, but quick look-see last night resulted in
> "error: 'CurrentTokenDataPtr' was not declared in this scope".  (looks like the
> code bases have diverged.. ;-))

Well, bummer. Perhaps the general approach I took would still fly with 
code changes not too major to work with v3.8 b2?

> 
> re Ubuntu.  Debian now packs all/bin/  in/usr/bin/, and makes the former a
> symlink; more Windows mid nineties than Linux 🙁.

:-)

Bill P.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.