Hi, I typically work on Windows and Unix. Our network has a bunch of shared drives that I can access from both Windows and Unix by using the form: //filesystem/some/path/ It looks like boost::filesystem is getting rid of the double slash at the beginning and replacing it with a single slash. This will work on Unix but WIndows needs the double slashes. Any way around this? thanks, matthew ************************************ This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Industries, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this e-mail. ************************************
At 02:42 PM 1/13/2005, matthew.j.polder@itt.com wrote:
Hi,
I typically work on Windows and Unix. Our network has a bunch of shared drives that I can access from both Windows and Unix by using the form:
//filesystem/some/path/
It looks like boost::filesystem is getting rid of the double slash at the
beginning and replacing it with a single slash. This will work on Unix but WIndows needs the double slashes. Any way around this?
The Windows regression tests contain lots of tests in the form //filesystem/some/path... for native paths so there shouldn't be any problem from Windows. On the Unix side, I'd need more information to figure out what is going on. For example, what Unix? What compiler? What software is the Unix system using to access paths on Windows machines? Do you do mounts, or is some other mechanism used? Do you have a sample of code you expect to work? --Beman
The following program sustains a segfault and, since the program is so simple, I have to believe the problem lies in my setup/system/build. I hope someone can provide me with some advice as to how I might proceed to further diagnose this problem. To this end, I've provided my system configuration, the compiler and linker options, the source code of the offending program, and a gdb stack trace at the point at which the segfault was sustained. (1) Here's what uname -a reveals: linux 2.6.3-7mdk-i686-up-4GB #1 Wed Mar 17 15:17:23 CET 2004 i686 unknown unknown GNU/Linux (2) The code is compiled using g++ 3.3.2 with the following flags: -ggdb3 -Wall -Wstrict-prototypes -D__USE_POSIX -D_REENTRANT, (3) I link the compiled code against libboost_test_exec_monitor.so (V1.32.0) and libstlport_gcc.so (4.6.2). (4) Here's the source file -- Note that this is pure BOOST code. #include <boost/test/test_tools.hpp> bool test1() { return( true ); } int test_main( int argc, char * argv[] ) { BOOST_CHECK( test1() == true ); return( 0 ); } (5) Here is the gdb stack trace taken after the segfault. (gdb) run Starting program: /home/michael/sde/pthreads-1.0/src/private/test [Thread debugging using libthread_db enabled] [New Thread 1078715360 (LWP 3872)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1078715360 (LWP 3872)] 0x400bcd79 in _STL::locale::locale() () from /usr/local/lib/stlport/libstlport_gcc.so (gdb) bt #0 0x400bcd79 in _STL::locale::locale() () from /usr/local/lib/stlport/libstlport_gcc.so #1 0x4008c88d in _STL::ios_base::ios_base() () from /usr/local/lib/stlport/libstlport_gcc.so #2 0x0804d83b in basic_ios (this=0x400f05e8) at _ios.c:95 #3 0x4008e831 in _STL::basic_istream<char, _STL::char_traits<char>
::basic_istream(_STL::basic_streambuf<char, _STL::char_traits<char> >*) () from /usr/local/lib/stlport/libstlport_gcc.so #4 0x4009e04d in _STL::ios_base::_S_initialize() () from /usr/local/lib/stlport/libstlport_gcc.so #5 0x4009de56 in _STL::ios_base::Init::Init() () from /usr/local/lib/stlport/libstlport_gcc.so #6 0x40159675 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at iostream:75 #7 0x4015972b in _GLOBAL__I__ZN5boost9unit_test9ut_detail25msvc65_like_log_formatterC2ERK NS0_13unit_test_logE () at _iterator.h:153 #8 0x40159bb7 in __do_global_ctors_aux () from /usr/local/lib/boost/libboost_test_exec_monitor.so #9 0x401275d1 in _init () from /usr/local/lib/boost/libboost_test_exec_monitor.so #10 0x4000cdc9 in _dl_init (main_map=Variable "main_map" is not available. ) at dl-init.c:68 #11 0x40000ca5 in _dl_start_user () at dl-machine.h:400 (gdb)
Thanks, in advance Michael
I thought it might be more useful to show the stack trace produced when the test program is linked against the BOOST and STL static libs. (gdb) run Starting program: /home/michael/sde/pthreads-1.0/src/private/unit_test [Thread debugging using libthread_db enabled] [New Thread 1076290656 (LWP 4287)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076290656 (LWP 4287)] 0x0804aa67 in _M_assign_dispatch<char*> (this=0x48, __f=0x80d1940 "", __l=0x80d1940 "") at _string.h:626 626 pointer __cur = this->_M_start; (gdb) bt #0 0x0804aa67 in _M_assign_dispatch<char*> (this=0x48, __f=0x80d1940 "", __l=0x80d1940 "") at _string.h:626 #1 0x0804aa58 in assign<char*> (this=0x48, __first=0x80d1940 "", __last=0x80d1940 "") at _string.h:644 #2 0x0804a882 in _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >::operator=(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&) (this=0x48, __s=@0xbffff300) at _string.h:309 #3 0x0804a3fa in _STL::basic_ios<char, _STL::char_traits<char>
::imbue(_STL::locale const&) (this=0x0, __loc=@0x0) at _ios.c:83 (gdb)
Here, again, is the source code: #include <boost/test/test_tools.hpp> bool test1() { return( true ); } int test_main( int argc, char * argv[] ) { BOOST_CHECK( test1() == true ); return( 0 ); } Cheers, Michael -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Michael Peterson Sent: Friday, January 14, 2005 11:54 AM To: boost-users@lists.boost.org Subject: [Boost-users] Seg Fault in Boost/STL? The following program sustains a segfault and, since the program is so simple, I have to believe the problem lies in my setup/system/build. I hope someone can provide me with some advice as to how I might proceed to further diagnose this problem. To this end, I've provided my system configuration, the compiler and linker options, the source code of the offending program, and a gdb stack trace at the point at which the segfault was sustained. (1) Here's what uname -a reveals: linux 2.6.3-7mdk-i686-up-4GB #1 Wed Mar 17 15:17:23 CET 2004 i686 unknown unknown GNU/Linux (2) The code is compiled using g++ 3.3.2 with the following flags: -ggdb3 -Wall -Wstrict-prototypes -D__USE_POSIX -D_REENTRANT, (3) I link the compiled code against libboost_test_exec_monitor.so (V1.32.0) and libstlport_gcc.so (4.6.2). (4) Here's the source file -- Note that this is pure BOOST code. #include <boost/test/test_tools.hpp> bool test1() { return( true ); } int test_main( int argc, char * argv[] ) { BOOST_CHECK( test1() == true ); return( 0 ); } (5) Here is the gdb stack trace taken after the segfault. (gdb) run Starting program: /home/michael/sde/pthreads-1.0/src/private/test [Thread debugging using libthread_db enabled] [New Thread 1078715360 (LWP 3872)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1078715360 (LWP 3872)] 0x400bcd79 in _STL::locale::locale() () from /usr/local/lib/stlport/libstlport_gcc.so (gdb) bt #0 0x400bcd79 in _STL::locale::locale() () from /usr/local/lib/stlport/libstlport_gcc.so #1 0x4008c88d in _STL::ios_base::ios_base() () from /usr/local/lib/stlport/libstlport_gcc.so #2 0x0804d83b in basic_ios (this=0x400f05e8) at _ios.c:95 #3 0x4008e831 in _STL::basic_istream<char, _STL::char_traits<char>
::basic_istream(_STL::basic_streambuf<char, _STL::char_traits<char> >*) () from /usr/local/lib/stlport/libstlport_gcc.so #4 0x4009e04d in _STL::ios_base::_S_initialize() () from /usr/local/lib/stlport/libstlport_gcc.so #5 0x4009de56 in _STL::ios_base::Init::Init() () from /usr/local/lib/stlport/libstlport_gcc.so #6 0x40159675 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at iostream:75 #7 0x4015972b in _GLOBAL__I__ZN5boost9unit_test9ut_detail25msvc65_like_log_formatterC2ERK NS0_13unit_test_logE () at _iterator.h:153 #8 0x40159bb7 in __do_global_ctors_aux () from /usr/local/lib/boost/libboost_test_exec_monitor.so #9 0x401275d1 in _init () from /usr/local/lib/boost/libboost_test_exec_monitor.so #10 0x4000cdc9 in _dl_init (main_map=Variable "main_map" is not available. ) at dl-init.c:68 #11 0x40000ca5 in _dl_start_user () at dl-machine.h:400 (gdb)
Thanks, in advance Michael _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Michael Peterson wrote:
I thought it might be more useful to show the stack trace produced when the test program is linked against the BOOST and STL static libs.
It's a good idea to put the name of the Boost library you're having trouble with in the subject line of your message, as I have done here. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Michael Peterson" <mtp1032@comcast.net> wrote in message news:003301c4fa85$0c9d8260$1d02a8c0@wxp2000...
I thought it might be more useful to show the stack trace produced when the test program is linked against the BOOST and STL static libs.
Well, that backtrace doesn't show any references to Boost.Test. I think you could get more information on STLPort forum. Gennadiy
Gennadiy Rozental wrote:
"Michael Peterson" <mtp1032@comcast.net> wrote in message news:003301c4fa85$0c9d8260$1d02a8c0@wxp2000...
I thought it might be more useful to show the stack trace produced when the test program is linked against the BOOST and STL static libs.
Well, that backtrace doesn't show any references to Boost.Test.
The backtrace posted earlier in the thread does show references to Boost.Test, FWIW -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Well, that backtrace doesn't show any references to Boost.Test.
The backtrace posted earlier in the thread does show references to Boost.Test, FWIW
What it showed is global/static variables initialization, which includes unit_test_log, which refer to the std::ostream globals. And the crash happened somewhere inside iostream library. Gennadiy
Gennadiy Rozental wrote:
Well, that backtrace doesn't show any references to Boost.Test.
The backtrace posted earlier in the thread does show references to Boost.Test, FWIW
What it showed is global/static variables initialization, which includes unit_test_log, which refer to the std::ostream globals. And the crash happened somewhere inside iostream library.
Okay, sorry. I didn't look very closely. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
Beman Dawes -
David Abrahams -
Gennadiy Rozental -
matthew.j.polder＠itt.com -
Michael Peterson