On Thu, 16 Jul 2009 15:33:38 -0400 marabou wrote:

> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
> 
>> Le 15/07/2009 19:40, clipka nous fit lire :
>>> Le_Forgeron <jgr### [at] freefr> wrote:
>>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate
>>>> freebsd 7.2 and lower for not having it ? (no assertion about 8.0)
>>> 
>>> Sounds like a reasonable option :P (SCNR)
>>> 
>>> I'd say it depends on how complicated it would be to fix. At any rate,
>>> it's worth entering into the bugtracker as a compatibility issue. As
>>> you seem to be into details to some degree, would you mind...? kthxbye
>>> ;)
>>> 
>>> 
>>> 
>> Entry add in bugtracker, as per request.
> 
> Povray does compile now. The patch follows. But there is another problem
> which is ugly:
> [..]
> Making all in libraries
> Making all in source
> Making all in backend
> Making all in base
> Making all in frontend
> Making all in vfe
> Making all in unix
> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240
> +a0.3 +L./include
> povray: this pre-release version of POV-Ray for Unix has expired ***
> Error code 1
> 
> Stop in /usr/home/user/sources/povray-3.7.0.beta.32.
> 
> How can I circumvent it?
[..]
okay, fulfilled.
Sometimes Povray dumps core, sometimes it loops forever at this position:
Making all in libraries
Making all in source
Making all in backend
Making all in base
Making all in frontend
Making all in vfe
Making all in unix
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
+a0.3 +L./include
povray: this pre-release version of POV-Ray for Unix expires in 3 day(s) 
and 1 hour(s)
PATHS
  HOME        = /home/xxx
  SYSCONF     = /usr/local/etc/povray/3.7/povray.conf
  USERCONF    = /home/user/.povray/3.7/povray.conf
  SYSINI      = /usr/local/etc/povray/3.7/povray.ini
  SYSINI_OLD  = /usr/local/etc/povray.ini
  USERINI     = /home/xxx/.povray/3.7/povray.ini
  USERINI_OLD = /home/xxx/.povrayrc
PARSE CONF '/usr/local/etc/povray/3.7/povray.conf'
[still running@100% CPU time...]

There seems to be another problem.

GDB says:
#13 0x0yyyyyyy in SignalHandler () at unix/unixconsole.cpp:146
Previous frame identical to this frame (corrupt stack?)
(gdb) list 146
141		int      signum;
142	
143		while(true)
144		{
145			sigfillset(&sigset);
146			sigwait(&sigset, &signum);  // wait till a signal 
is caught
147			boost::mutex::scoped_lock lock(gSignalMutex);
148			gSignalNumber = signum;
149		}
150	}
(gdb)

Post a reply to this message