Re: [Quickfix-users] solaris 8 SIGSEV

[Oren M. <or...@qu...>]

Guido,

It looks like the crash is happening inside the STL, which I can't 
really explain.  I don't know, maybe there is something wrong with the 
installation.  Maybe try compiling against STL port and see if you 
still get such problems.

--oren

On Oct 14, 2004, at 2:28 AM, Guido Landi wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> i think you you mean this saying 'full stack trace'(but not so sure):
>
> root@ssfdb # /usr/local/bin/gdb ./ut
> GNU gdb 6.0
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
> details.
> This GDB was configured as "sparc-sun-solaris2.8"...
> (gdb) set arg '-p 1025'
> (gdb) run
> Starting program: /export/home/zeuli/svil/quickfix/src/.libs/ut '-p 
> 1025'
> [New LWP 1]
> [New LWP 2]
> [New LWP 3]
> <ut>
>   <output>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string const,
> std::string>, std::_Select1st<std::pair<std::string const, 
> std::string> >,
> std::less<std::string>, std::allocator<std::pair<std::string const,
> std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
> __k=@0xff369034) at stl_tree.h:496
> 496           { return static_cast<_Const_Link_type>(__x->_M_right); }
> (gdb) bt
> #0  0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string 
> const,
> std::string>, std::_Select1st<std::pair<std::string const, 
> std::string> >,
> std::less<std::string>, std::allocator<std::pair<std::string const,
> std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
> __k=@0xff369034) at stl_tree.h:496
> #1  0xff2bd4a0 in FIX::Dictionary::getString(std::string const&, bool)
> const (
>     this=0xffbe6eb0, key=@0xff369034, capitalize=false) at 
> stl_map.h:513
> #2  0xff2b02cc in FIX::operator>>(std::istream&, 
> FIX::SessionSettings&) (
>     stream=@0xffbe6eb0, s=@0xff369034) at Fields.h:40
>
>
>
>
>> Guido,
>>
>> QuickFIX will not work with 2.96 even if you does compile.  Regardless
>> of the status of QF with this compiler, I wouldn't recommend any C++
>> development be done with it.  See this note from the gcc team:
>> http://gcc.gnu.org/gcc-2.96.html.  I would recommend upgrading to a 
>> 3.x
>> compiler or dropping down to 2.95
>>
>> As per your Solaris problems, can you provide a full stack trace
>> instead of a system call trace?
>>
>> --oren
>>
>> On Oct 13, 2004, at 9:38 AM, Guido Landi wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX FAQ:
>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>> hi list,
>>>
>>> i'm trying to use quickfix on solaris 8(sparc) but i have encoutered
>>> many
>>> problems:
>>> i can build version 1.9.0(with gnu-gcc and all dependancies listed on
>>> the
>>> INSTALL doc as the latest version found at sunfreeware.com) but all 
>>> the
>>> binary received a SIGSEV from the system, here is the output of the 
>>> ut
>>> test:
>>>
>>> root@ssfdb # ./ut -p 1025
>>> <ut>
>>>   <output>
>>> Segmentation Fault - core dumped
>>>
>>> And here is the ending part of a strace:
>>>
>>> ioctl(1, TCGETA, 0xFFBE6F8C)                    = 0
>>> <ut>
>>> write(1, " < u t >\n", 5)                       = 5
>>>   <output>
>>> write(1, "     < o u t p u t >\n", 11)          = 11
>>> open("/usr/share/lib/zoneinfo/MET", O_RDONLY)   = 3
>>> read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 755
>>> close(3)                                        = 0
>>> brk(0x00283660)                                 = 0
>>> brk(0x00285660)                                 = 0
>>> sigaction(SIGPIPE, 0xFFBE7010, 0x00000000)      = 0
>>> brk(0x00285660)                                 = 0
>>> brk(0x00289660)                                 = 0
>>>     Incurred fault #6, FLTBOUNDS  %pc = 0xFF3172A4
>>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>>     Received signal #11, SIGSEGV [default]
>>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>>         *** process killed ***
>>> root@me#
>>>
>>> has anyone experienced similar problem, or can anyone use quickfix on
>>> solaris without problems?
>>>
>>> 1.9.2 build but on my system but say:
>>> BUILD SUCCESSFUL
>>> [...]
>>> gcc -g -O2 -I/usr/local/include/libxml2 -I/include -I/include/solaris
>>> -o
>>> .libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib
>>> -L/usr/openwin/lib -L/usr/local/ssl/lib -lrt 
>>> /usr/local/lib/libxml2.so
>>> -lz
>>> -lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty
>>> -R/usr/local/lib
>>> Undefined                       first referenced
>>>  symbol                             in file
>>> std::basic_ifstream<char, std::char_traits<char> 
>>> >::basic_ifstream(char
>>> const*, std::_Ios_Openmode)C++/.libs/libquickfix.so
>>> [many other messages like this]
>>> ld: fatal: Symbol referencing errors. No output written to .libs/at
>>> collect2: ld returned 1 exit status
>>> *** Error code 1
>>>
>>> After stracing and debugging(with gdb) with no results(my c and unix
>>> internals skills are not enough) i tried to compile 1.9.2 on linux 
>>> and
>>> found another problem.  Dependencies on INSTALL docs does not 
>>> specify a
>>> gcc version to use, so i try with a RedHat AES 2.1 that comes with 
>>> gcc
>>> 2.96 but it wont compile saying:
>>>
>>> In file included from ../Field.h:32,
>>>                  from FieldBaseTestCase.h:26,
>>>                  from FieldBaseTestCase.cpp:27:
>>> ../FieldConvertors.h:32:18: limits: No such file or directory
>>>
>>> note that i can find a *ulimits* include for C++ on my system(that 
>>> seem
>>> something like a forward on the C limits.h)or a *limits.h* include 
>>> for
>>> plain C.
>>>
>>> After all i try with a version of SuSE that comes with gcc3 and it
>>> magically works!! ...but unfortunately i can't use SuSE for doing 
>>> that
>>> work.
>>>
>>>
>>> any hints or help would be appreciated!
>>> Guido Landi.
>>>
>>> p.s.
>>> excuse me but my english is poor as you can see!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on
>>> ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them. 
>>> Give
>>> us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>>> out
>>> more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Quickfix-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>>
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>