Le 21/06/2011 15:20, Jan-Philip Gehrcke a écrit :
> The first insight for me is that my system insists on
> using the libboost_thread.so.1.36.0 although libboost_thread.so and
> libboost_thread.so.1.46.1 are in my LD_LIBRARY_PATH. I am wondering why
> povray is specifically searching for the version 1.36.0? Was this fixed during
> compile time (how does that make sense, configure says: checking for boostlib >=
> 1.37... yes?)?.

Well, the linker stage only request libboost_thread.so, or I hope so.
(with the -l directive in the unix/Makefile)
It's the embedded loader inside povray binary which solves it as 1.36
(or maybe the linker ld itself).

Have you granted trust to the local boost library (running ldconfig
after update of /etc/ld.so.conf (or whatever)) ?
(well, you need superuser access to do that...)

I still wonder what is doing the binary.
Could you reconfigure with --enable-debug and when running "make check",
attach a debugger on the povray process ?
and then display the stack (on gdb/ddd: "where" )

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Well, the linker stage only request libboost_thread.so, or I hope so.
> (with the -l directive in the unix/Makefile)
> It's the embedded loader inside povray binary which solves it as 1.36
> (or maybe the linker ld itself).
>
> Have you granted trust to the local boost library (running ldconfig
> after update of /etc/ld.so.conf (or whatever)) ?
> (well, you need superuser access to do that...)
Yeah, I'll bother our admin only if this will be really necessary -- so let's
see how far we get without him. At the moment we can be pretty sure that povray
uses my libboost_thread.so.1.46.1 (for the debug output below keep in mind that
my /home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0 still links to the
1.46.1 version)

> I still wonder what is doing the binary.
> Could you reconfigure with --enable-debug and when running "make check",
> attach a debugger on the povray process ?
> and then display the stack (on gdb/ddd: "where" )

(gdb) attach 4277
Attaching to process 4277
Reading symbols from
/home/bioinfp/jang/sumpf/povray-3.7.0.RC3/unix/povray...done.
Reading symbols from /usr/lib64/libSDL-1.2.so.0...done.
Loaded symbols for /usr/lib64/libSDL-1.2.so.0
Reading symbols from /lib64/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x2b98e31c7950 (LWP 4278)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libXpm.so.4...done.
Loaded symbols for /usr/lib64/libXpm.so.4
Reading symbols from /usr/lib64/libSM.so.6...done.
Loaded symbols for /usr/lib64/libSM.so.6
Reading symbols from /usr/lib64/libICE.so.6...done.
Loaded symbols for /usr/lib64/libICE.so.6
Reading symbols from /usr/lib64/libX11.so.6...done.
Loaded symbols for /usr/lib64/libX11.so.6
Reading symbols from /usr/lib64/libIlmImf.so.6...done.
Loaded symbols for /usr/lib64/libIlmImf.so.6
Reading symbols from /lib64/libz.so.1...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /usr/lib64/libImath.so.6...done.
Loaded symbols for /usr/lib64/libImath.so.6
Reading symbols from /usr/lib64/libHalf.so.6...done.
Loaded symbols for /usr/lib64/libHalf.so.6
Reading symbols from /usr/lib64/libIex.so.6...done.
Loaded symbols for /usr/lib64/libIex.so.6
Reading symbols from /usr/lib64/libIlmThread.so.6...done.
Loaded symbols for /usr/lib64/libIlmThread.so.6
Reading symbols from /usr/lib64/libtiff.so.3...done.
Loaded symbols for /usr/lib64/libtiff.so.3
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /lib64/librt.so.1...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0...done.
Loaded symbols for /home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0
Reading symbols from /usr/lib64/libstdc++.so.6...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libXext.so.6...done.
Loaded symbols for /usr/lib64/libXext.so.6
Reading symbols from /usr/lib64/libXrandr.so.2...done.
Loaded symbols for /usr/lib64/libXrandr.so.2
Reading symbols from /usr/lib64/libXrender.so.1...done.
Loaded symbols for /usr/lib64/libXrender.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libuuid.so.1...done.
Loaded symbols for /lib64/libuuid.so.1
Reading symbols from /usr/lib64/libxcb-xlib.so.0...done.
Loaded symbols for /usr/lib64/libxcb-xlib.so.0
Reading symbols from /usr/lib64/libxcb.so.1...done.
Loaded symbols for /usr/lib64/libxcb.so.1
Reading symbols from /usr/lib64/libXau.so.6...done.
Loaded symbols for /usr/lib64/libXau.so.6
0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) where
#0  0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x00002b98dec492a2 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002b98e151e552 in std::basic_istream<char, std::char_traits<char> >&
std::getline<char, std::char_traits<char>, std::allocator<char>
>(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, char) () from
/usr/lib64/libstdc++.so.6
#3  0x0000000000430bd0 in vfePlatform::UnixOptionsProcessor::parse_conf_file (
    this=0x92f7b0, Stream=@0x7fffb8f87850, conf_name=@0x92f7d8, user_mode=true)
    at unix/unixoptions.cpp:817
#4  0x0000000000431fe7 in vfePlatform::UnixOptionsProcessor::process_povray_conf
(this=0x92f7b0) at unix/unixoptions.cpp:1052
#5  0x0000000000432768 in UnixOptionsProcessor (this=0x92f7b0,
    session=<value optimized out>) at unix/unixoptions.cpp:195
#6  0x000000000042b000 in vfeUnixSession (this=0x92f2a0,
    id=<value optimized out>) at unix/vfeplatform.cpp:133
#7  0x000000000043e141 in main (argc=10, argv=0x7fffb8f881e8)
    at unix/unixconsole.cpp:452
(gdb)

Post a reply to this message

Le 21/06/2011 17:30, Jan-Philip Gehrcke nous fit lire :
> [Thread debugging using libthread_db enabled]
> [New Thread 0x2b98e31c7950 (LWP 4278)]

It can be interesting to look also at that thread too, as it might have
the mutex the main thread is expecting.

gdb command would be "info threads"
then "thread <number_of_the_thread_for_gdb>"
and "where" once there.

> 0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
> (gdb) where
> #0  0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1  0x00002b98dec492a2 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002b98e151e552 in std::basic_istream<char, std::char_traits<char> >&
> std::getline<char, std::char_traits<char>, std::allocator<char>
>> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >&, char) () from
> /usr/lib64/libstdc++.so.6
> #3  0x0000000000430bd0 in vfePlatform::UnixOptionsProcessor::parse_conf_file (
>     this=0x92f7b0, Stream=@0x7fffb8f87850, conf_name=@0x92f7d8, user_mode=true)
>     at unix/unixoptions.cpp:817
> #4  0x0000000000431fe7 in vfePlatform::UnixOptionsProcessor::process_povray_conf
> (this=0x92f7b0) at unix/unixoptions.cpp:1052
> #5  0x0000000000432768 in UnixOptionsProcessor (this=0x92f7b0,
>     session=<value optimized out>) at unix/unixoptions.cpp:195
> #6  0x000000000042b000 in vfeUnixSession (this=0x92f2a0,
>     id=<value optimized out>) at unix/vfeplatform.cpp:133
> #7  0x000000000043e141 in main (argc=10, argv=0x7fffb8f881e8)
>     at unix/unixconsole.cpp:452
> (gdb)

It could be interesting to up to #3 to get more information about Stream
(and line_number of unixoptions.cpp... parse_conf_file() )

For the time-being, it looks like a mutex-lock for that thread, done by
the system itself.

Are you somehow on a NFS mounted filesysem ? (like "your home is mounted
everywhere, whatever the system you log in" ?)

I'm used to --disable-io-restrictions for configure, you might give it a
try (at least for the experiment).

I wonder a bit about the construct

		while ( !Stream.eof() )
		{
			// get and preprocess line
			std::getline(Stream, line);
			line = pre_process_conf_line(line);
			++line_number;

			// skip empty line
			if(line.length() == 0)
				continue;

If the last line is length 0, would the eof() be evaluated (again) ?

Post a reply to this message

Am 21.06.2011 20:36, schrieb Le_Forgeron:

> I wonder a bit about the construct
>
> 		while ( !Stream.eof() )
> 		{
> 			// get and preprocess line
> 			std::getline(Stream, line);
> 			line = pre_process_conf_line(line);
> 			++line_number;
>
> 			// skip empty line
> 			if(line.length() == 0)
> 				continue;
>
> If the last line is length 0, would the eof() be evaluated (again) ?

The C/C++ language construct

     while ( <CONDITION_1> )
     {
         <STATEMENTS_A>
         if ( <CONDITION_2> ) continue;
         <STATEMENTS_B>
     }

is fully equivalent to

     while ( <CONDITION_1> )
     {
         <STATEMENTS_A>
         if ( ! <CONDITION_2> )
         {
             <STATEMENTS_B>
         }
     }

Post a reply to this message

Le 21/06/2011 21:30, clipka a écrit :
> Am 21.06.2011 20:36, schrieb Le_Forgeron:
> 
>> I wonder a bit about the construct
>>
>>         while ( !Stream.eof() )
>>         {
>>             // get and preprocess line
>>             std::getline(Stream, line);
>>             line = pre_process_conf_line(line);
>>             ++line_number;
>>
>>             // skip empty line
>>             if(line.length() == 0)
>>                 continue;
>>
>> If the last line is length 0, would the eof() be evaluated (again) ?
> 
> The C/C++ language construct
> 
>     while ( <CONDITION_1> )
>     {
>         <STATEMENTS_A>
>         if ( <CONDITION_2> ) continue;
>         <STATEMENTS_B>
>     }
> 
> is fully equivalent to
> 
>     while ( <CONDITION_1> )
>     {
>         <STATEMENTS_A>
>         if ( ! <CONDITION_2> )
>         {
>             <STATEMENTS_B>
>         }
>     }

Ok, thanks for the check. So that (i.e. loop with continue not detecting
the end of file) was a red herring.

In the meantime, I compiled on a Red Hat Server 6.1 /x86_64, and it
works fine too (once I installed boost
 and add the infamous --with-boost-thread=boost_thread_mt to configure)
(It's boost 1.41)

Alas, I have no Suse available.

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Trying to provide more ideas to Jan-Philip Gehrcke:

> ../configure --prefix=/home/bioinfp/jang/apps/povray37
> --with-boost-thread=boost_thread-mt COMPILED_BY="foo" CFLAGS="-I $BOOST_ROOT"
> CXXFLAGS="-I $BOOST_ROOT"

I wonder about the need for ../ ?
Shouldn't it be "./configure", ran from the root directory of the sources ?

Also, on my "never installed any povray on this" system, there is two
complains about "cannot open file"

> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3
+L./include
> povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is
discouraged.
> povray: cannot open the system configuration file
/home/grimbert/povray37/etc/povray/3.7/povray.conf: No such file or directory
> povray: cannot open the user configuration file
/home/grimbert/.povray/3.7/povray.conf: No such file or directory
> povray: I/O restrictions are disabled
> Persistence of Vision(tm) Ray Tracer Version 3.7.0.RC3 (g++ 4.4.5 @
>  x86_64-unknown-linux-gnu)
> This is a release candidate of POV-Ray version 3.7.0.
> General distribution is strongly discouraged.

Whereas, in Jan-Philip Gehrcke log, there is only one complains and then
it stucks (or whatever).
Could it be that there is already something
in $HOME/.povray/3.7/povray.conf ???



-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> I wonder a bit about the construct
>
>   while ( !Stream.eof() )
>   {
>    // get and preprocess line
>    std::getline(Stream, line);
>    line = pre_process_conf_line(line);
>    ++line_number;
>
>    // skip empty line
>    if(line.length() == 0)
>     continue;
>

In my case, this loop was an endless loop. line.length() was always 0 and the
Stream.eof() never returned true (at least I checked this until line_number =
9).

I was interested in which file was actually parsed here:

(gdb) print conf_name
$7 = (const std::locale::string &) @0x92f7f8: {
  static npos = 18446744073709551615,
  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>},
    _M_p = 0x92f928 "/home/bioinfp/jang/.povray/3.7/povray.conf"}}

And now it gets funny:

ls -ahl /home/bioinfp/jang/.povray/3.7/
[...]
1.5K drwxr-xr-x 2 jang bioinfp 2 2011-06-08 15:50 povray.conf/

povray.conf was a directory in my case. I removed it, restarted 'make check' and
the test worked fine (X window opened..."POV-Ray finished").

I think the path /home/bioinfp/jang/.povray/3.7/ existed due to some former
tries of myself to 'make install' povray. I have no idea why this povray.conf
existed as a _directory_ -- it may be my fault from earlier times. But you maybe
could add some more dir/file checking so that povray never tries to read lines
from a directory :-)

I removed ~/povray and invoked 'make install'. Now, there is only one small
problem left:

Creating data directories...
Copying data files...
Creating documentation directories...
Copying documentation files...
Creating user directories...
chown: changing ownership of `/home/bioinfp/jang/.povray': Operation not
permitted
chown: changing ownership of `/home/bioinfp/jang/.povray/3.7': Operation not
permitted
make[2]: *** [install-data-local] Error 1
make[2]: Leaving directory `/home/bioinfp/jang/sumpf/povray-3.7.0.RC3'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/bioinfp/jang/sumpf/povray-3.7.0.RC3'
make: *** [install-recursive] Error 1

The installation works, but what does the make script try to do with the
permissions? And yes, my home directory is a mounted NFS.

Thanks for your help,

Jan-Philip

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Trying to provide more ideas to Jan-Philip Gehrcke:
>
> > ../configure --prefix=/home/bioinfp/jang/apps/povray37
> > --with-boost-thread=boost_thread-mt COMPILED_BY="foo" CFLAGS="-I $BOOST_ROOT"
> > CXXFLAGS="-I $BOOST_ROOT"
>
> I wonder about the need for ../ ?
> Shouldn't it be "./configure", ran from the root directory of the sources ?

Yes, I executed ./configure. That was only a 'typo' in the mail.


> Whereas, in Jan-Philip Gehrcke log, there is only one complains and then
> it stucks (or whatever).
> Could it be that there is already something
> in $HOME/.povray/3.7/povray.conf ???

I should have read this mail before starting gdb. You would have brought me on
the right track easier :-) Sorry for all the excitement just due to this stupid
directory.

JP

Post a reply to this message

Am 22.06.2011 11:10, schrieb Jan-Philip Gehrcke:

> In my case, this loop was an endless loop. line.length() was always 0 and the
> Stream.eof() never returned true (at least I checked this until line_number =
> 9).
>
> I was interested in which file was actually parsed here:
...
> povray.conf was a directory in my case. I removed it, restarted 'make check' and
> the test worked fine (X window opened..."POV-Ray finished").

Duh - I guess we have a problem there.

Next question that arises here: Is this problem limited to reading of 
Unix config files (or should we say directories? :-)), or does it also 
happen with other text file read accesses, e.g. a scene or INI file? And 
is this a Unix-specific issue, or does it also affect Windows?

I guess there's work to do now; an endless loop is /not/ an acceptable 
mode of failure. Thanks for finding this bug. Would you mind filing a 
bug report on http://bugs.povray.org?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 22.06.2011 11:10, schrieb Jan-Philip Gehrcke:
>
> > In my case, this loop was an endless loop. line.length() was always 0 and the
> > Stream.eof() never returned true (at least I checked this until line_number =
> > 9).
> >
> > I was interested in which file was actually parsed here:
> ...
> > povray.conf was a directory in my case. I removed it, restarted 'make check' and
> > the test worked fine (X window opened..."POV-Ray finished").
>
> Duh - I guess we have a problem there.
>
> Next question that arises here: Is this problem limited to reading of
> Unix config files (or should we say directories? :-)), or does it also
> happen with other text file read accesses, e.g. a scene or INI file? And
> is this a Unix-specific issue, or does it also affect Windows?
>
> I guess there's work to do now; an endless loop is /not/ an acceptable
> mode of failure. Thanks for finding this bug. Would you mind filing a
> bug report on http://bugs.povray.org?

Of course, here it is: http://bugs.povray.org/task/213
As it turns out, the fix in this specific function is pretty simple. But maybe
there are more of these things?

JP

Post a reply to this message