 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
>
> The debugging you all have done has been helpful to me. Thanks!
>
> Short on time but, I think we are seeing two different failure
> mechanisms, the second being tangled in the fix for Ingo's spline issue
> from July 2021...
That was some good and fast detective work! I was hoping that you would take a
look. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
>
> A #local has to be declared in a temporary location, then released when
> the macro returns. This is opportunity for an allocation/de-allocation
> mix-up that doesn't occur with #declare.
Ah, I see. I don't know much about the subtle(?) inner code-workings of #local
vs. #declare, but I grasp the idea. I arrived at my 'fix' in my usual way--
trial-and-error guesswork, ha.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
