Trying to get 3.50c to work on linux, Debian 3.0 systems (dual Pentium ||| 
systems). It actually works *great* (kudos to the devels)... except (you 
*did* expect an 'except' in a bug report, right?) when doing something like

rsh othermachine ~/pov/pov.sh

or

qsub ./pov.sh

where pov.sh is something akin to 

cd ~/pov
povray [params]

It dies with a Segmentation Fault.

Debian's packaged 3.0 does not have that problem. Redirecting output doesn't 
seem to help at all. The +GA command option is not helping either.

Can anyone confirm the bug on other linuxes? Provide a fix? (Setting TERM to 
something magic?)

Have fun,
Chris

Post a reply to this message

In article <3dc98005@news.povray.org> , Christian Lavoie 
<cla### [at] po-boxmcgillca>  wrote:

> It dies with a Segmentation Fault.
>
> Debian's packaged 3.0 does not have that problem. Redirecting output doesn't
> seem to help at all. The +GA command option is not helping either.

You are not by any chance trying to use display without having X configured
or something similar?  Essentially your problem is most likely related to
the fact that the 3.5 binary is a kind of hybrid, while the Debian package
might just be a plain command line version without X output support.

In any case, as you may have noticed this group not being filled with notes
that the Linux version does not work Linux systems, you may want to check
your system configuration carefully, and regarding the X issue, check older
messages in this group.  I can't promise it will help you solve your
problem, but probably give you some pointers what to check first...

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3dc98005@news.povray.org> , Christian Lavoie
> <cla### [at] po-boxmcgillca>  wrote:
> 
>> It dies with a Segmentation Fault.
>>
>> Debian's packaged 3.0 does not have that problem. Redirecting output
>> doesn't seem to help at all. The +GA command option is not helping
>> either.
> 
> You are not by any chance trying to use display without having X
> configured
> or something similar?  

Not as far as I know. Been thru the manpages repeatedly, nothing there 
sounds like it could cause this.

/usr/local/bin/povray +Ibasic.pov +Obasic.tga +H800 +W800

What exactly could go wrong with *nothing* turned on?

X -- nope. $DISPLAY is not set anyway.
Stream redirection -- didn't help.
UNIX stdout/err redirection, etc -- didn't help.

In any cases, a segfault wasn't what I expected.

> Essentially your problem is most likely related to
> the fact that the 3.5 binary is a kind of hybrid, while the Debian package
> might just be a plain command line version without X output support.

3.5 works great *unless* I have some sort of non-terminal usage. If I rsh to 
a machine and THEN start it, it works. If I rsh to the *same* machine and 
pass the script to rsh as the command to execute, it dies.

If I throw it through the queueing system (PBS as it happens), it dies. If I 
rsh to the same machine pbs scheduled it and then run it -- wonderful.

I've compared the environment variables. There wasn't anything that could 
cause segfaults in there -- as far as I could tell.

> In any case, as you may have noticed this group not being filled with
> notes that the Linux version does not work Linux systems, you may want to
> check your system configuration carefully, and regarding the X issue,
> check older
> messages in this group.  I can't promise it will help you solve your
> problem, but probably give you some pointers what to check first...

Thanx anyway.

Have fun,
Chris

Post a reply to this message

On Wed, 06 Nov 2002 15:48:03 +0000, Christian Lavoie wrote:

> Trying to get 3.50c to work on linux, Debian 3.0 systems (dual Pentium
> ||| systems). It actually works *great* (kudos to the devels)... except
> (you *did* expect an 'except' in a bug report, right?) when doing
> something like
> 
> rsh othermachine ~/pov/pov.sh
> 
> or
> 
> qsub ./pov.sh
> 
> where pov.sh is something akin to
> 
> cd ~/pov
> povray [params]
> 
> It dies with a Segmentation Fault.

Can you confirm that this works on this machine otherwise? I want to make
sure the rsh isn't a red herring.
 
> Debian's packaged 3.0 does not have that problem. Redirecting output
> doesn't seem to help at all. The +GA command option is not helping
> either.

A number of things have changed since 3.0.

> Can anyone confirm the bug on other linuxes? Provide a fix? (Setting
> TERM to something magic?)

I am unable to confirm using ssh from Mandrake 8.2 to Red Hat 7.3.  Then
again, it's passing my xauth and display, so it's even displaying properly
(though very slowly).  You may want to try ssh as an alternative to rsh (I
try to avoid rsh unless I'm very, very far from the Internet, which I'm
not at the moment).

-Mark Gordon

Post a reply to this message

Christian Lavoie <cla### [at] po-boxmcgillca> wrote:
> Not as far as I know. Been thru the manpages repeatedly, nothing there 
> sounds like it could cause this.

> /usr/local/bin/povray +Ibasic.pov +Obasic.tga +H800 +W800

> What exactly could go wrong with *nothing* turned on?

  Have you tried with -d

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>> It dies with a Segmentation Fault.
>
> Can you confirm that this works on this machine otherwise? I want to make
> sure the rsh isn't a red herring.

Yes, it works if I do

workstation:~$ rsh somecomp
somecompe:~$ ~/pov/tut/pov.sh

but not if I do
workstation:~$ rsh somecomp ~/pov/tut/pov.sh
or
workstation:~$ qsub ./pov.sh

and it's scheduled on somecomp

Lemme repeat myself: It works *great* on somecomp unless I use rsh to 
execute the script directly or the queueing system. It works *great* on 
workstation too, for all that's worth.

It would seem the common factor would be login vs non-login sessions. And 
since my .bash_profile sources bashrc directly, I can't see this changing a 
thing.
  
>> Debian's packaged 3.0 does not have that problem. Redirecting output
>> doesn't seem to help at all. The +GA command option is not helping
>> either.
> 
> A number of things have changed since 3.0.

Hopefully :)

>> Can anyone confirm the bug on other linuxes? Provide a fix? (Setting
>> TERM to something magic?)
> 
> I am unable to confirm using ssh from Mandrake 8.2 to Red Hat 7.3.  Then
> again, it's passing my xauth and display, so it's even displaying properly
> (though very slowly).  You may want to try ssh as an alternative to rsh (I
> try to avoid rsh unless I'm very, very far from the Internet, which I'm
> not at the moment).

I'm carefully avoiding X and all that on purpose. I *don't* want it to 
render to an X screen if I do it thru a queue =P.

Have fun,
Chris

Post a reply to this message

I'm also getting same effect.

here's what I'm seeing.

If I run on the local machine with X - sweet

if I run on the same machine with a remote X (16bit) seg fault, have to run 
with a -d option.

If i run via a vncserver (24 bit) same problem. Again have to use the -d 
option. 

This is running on a Duron 900 with 512 M Ram, running Debian Linux 
unstable.

Fran.

Mark Gordon wrote:

> On Wed, 06 Nov 2002 15:48:03 +0000, Christian Lavoie wrote:
> 
>> Trying to get 3.50c to work on linux, Debian 3.0 systems (dual Pentium
>> ||| systems). It actually works *great* (kudos to the devels)... except
>> (you *did* expect an 'except' in a bug report, right?) when doing
>> something like
>> 
>> rsh othermachine ~/pov/pov.sh
>> 
>> or
>> 
>> qsub ./pov.sh
>> 
>> where pov.sh is something akin to
>> 
>> cd ~/pov
>> povray [params]
>> 
>> It dies with a Segmentation Fault.
> 
> Can you confirm that this works on this machine otherwise? I want to make
> sure the rsh isn't a red herring.
>  
>> Debian's packaged 3.0 does not have that problem. Redirecting output
>> doesn't seem to help at all. The +GA command option is not helping
>> either.
> 
> A number of things have changed since 3.0.
> 
>> Can anyone confirm the bug on other linuxes? Provide a fix? (Setting
>> TERM to something magic?)
> 
> I am unable to confirm using ssh from Mandrake 8.2 to Red Hat 7.3.  Then
> again, it's passing my xauth and display, so it's even displaying properly
> (though very slowly).  You may want to try ssh as an alternative to rsh (I
> try to avoid rsh unless I'm very, very far from the Internet, which I'm
> not at the moment).
> 
> -Mark Gordon

Post a reply to this message

Addition to this... 

The vncserver method seems to be ok, BTW.


Fran Firman wrote:

> I'm also getting same effect.
> 
> here's what I'm seeing.
> 
> If I run on the local machine with X - sweet
> 
> if I run on the same machine with a remote X (16bit) seg fault, have to
> run with a -d option.
> 
> If i run via a vncserver (24 bit) same problem. Again have to use the -d
> option.
> 
> This is running on a Duron 900 with 512 M Ram, running Debian Linux
> unstable.
> 
> Fran.
> 
> Mark Gordon wrote:
> 
>> On Wed, 06 Nov 2002 15:48:03 +0000, Christian Lavoie wrote:
>> 
>>> Trying to get 3.50c to work on linux, Debian 3.0 systems (dual Pentium
>>> ||| systems). It actually works *great* (kudos to the devels)... except
>>> (you *did* expect an 'except' in a bug report, right?) when doing
>>> something like
>>> 
>>> rsh othermachine ~/pov/pov.sh
>>> 
>>> or
>>> 
>>> qsub ./pov.sh
>>> 
>>> where pov.sh is something akin to
>>> 
>>> cd ~/pov
>>> povray [params]
>>> 
>>> It dies with a Segmentation Fault.
>> 
>> Can you confirm that this works on this machine otherwise? I want to make
>> sure the rsh isn't a red herring.
>>  
>>> Debian's packaged 3.0 does not have that problem. Redirecting output
>>> doesn't seem to help at all. The +GA command option is not helping
>>> either.
>> 
>> A number of things have changed since 3.0.
>> 
>>> Can anyone confirm the bug on other linuxes? Provide a fix? (Setting
>>> TERM to something magic?)
>> 
>> I am unable to confirm using ssh from Mandrake 8.2 to Red Hat 7.3.  Then
>> again, it's passing my xauth and display, so it's even displaying
>> properly
>> (though very slowly).  You may want to try ssh as an alternative to rsh
>> (I try to avoid rsh unless I'm very, very far from the Internet, which
>> I'm not at the moment).
>> 
>> -Mark Gordon

Post a reply to this message