Re: opreport of oprofile 0.9.3 segmentation fault

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Reeve Yang wrote:
> I ran gdb on opreport, here is back trace. I appreciate if someone
> could help. I'm using oprofile to locate some performance issue which
> is a show stopper for my whole project. Thanks!
>   
Reeve,
Apparently the opreport program is failing to initialize.  On the face
of it, I would guess this is probably *not* a problem with oprofile, but
rather something wrong with your C++ environment.  I suggest you write a
small C++ program and compile it with your g++ compiler and see if it
runs OK.  Another reason I suspect something is messed up in your
development environment is the symptom of your build problem you
reported in your earlier note to Dave (see my comments below about
that).  Is it possible you have an older version of c++ development and
runtime in your path -- something that doesn't match your gcc
installation?  ('gcc --version' and 'g++ --version' should show the same
version.)

>
> Program received signal SIGSEGV, Segmentation fault.
> 0x080b3e91 in std::string::_M_replace_safe<__gnu_cxx::__normal_iterator<char*,
> std::string> > ()
> (gdb) bt
> #0  0x080b3e91 in
> std::string::_M_replace_safe<__gnu_cxx::__normal_iterator<char*,
> std::string> > ()
> #1  0x08087c77 in std::out_of_range::~out_of_range ()
> #2  0x0804fc81 in ?? ()
> #3  0x0805c05b in
> std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<std::string
> const*, std::vector<std::string, std::allocator<std::string> > >,
> std::string*> ()
> #4  0x0804fe6a in ?? ()
> #5  0x40198e16 in __libc_start_main () from /lib/libc.so.6
> #6  0x0804c661 in ?? ()
>
> On Fri, May 9, 2008 at 7:48 PM, Reeve Yang <ree...@gm...> wrote:
>   
>> Dave, I do have stacksize unlimited.
>>
>> bash-2.05a# ulimit -a
>> core file size        (blocks, -c) unlimited
>> data seg size         (kbytes, -d) unlimited
>> file size             (blocks, -f) unlimited
>> max locked memory     (kbytes, -l) 32
>> max memory size       (kbytes, -m) unlimited
>> open files                    (-n) 1024
>> pipe size          (512 bytes, -p) 8
>> stack size            (kbytes, -s) unlimited
>> cpu time             (seconds, -t) unlimited
>> max user processes            (-u) 3959
>> virtual memory        (kbytes, -v) unlimited
>>
>> When I compiled the oprofile-0.9.3 by doing "./configure
>> --with-kernel-support; make", I got following error:
>> bfd_spu_support.cpp: In function `bfd* spu_open_bfd(std::basic_string<char,
>>   std::char_traits<char>, std::allocator<char> >, int, long long unsigned
>>   int)':
>> bfd_spu_support.cpp:98: `bfd_openr_iovec' undeclared (first use this function)
>> bfd_spu_support.cpp:98: (Each undeclared identifier is reported only once for
>>     
There is a two-part configure check that's used for bfd_openr_iovec: 
the first part uses AC_CHECK_LIB to verify the symbol name can be found
in the bfd library;  the second part does AC_COMPILE_IFELSE to verify
the function has 7 parameters, implying it has the necessary Cell spu
target support needed by bfd_spu_support.cpp.  *BOTH* of these configure
checks must succeed in order for HAVE_BFD_OPENR_IOVEC_WITH_7PARMS to be
defined, so this configure check must have succeeded for you.  The key
thing to note about these two configure checks is that we're doing them
with C, not C++.  However, your compile failure above is happening when
using g++ and it's indicating it can't find bfd_openr_iovec in the . 
Please try the following and let me know the results:
  1. Edit m4/cellspubfdsupport.m4 and comment out (with 'dnl ') the
AC_PUSH_LANG and AC_POP_LANG.  This should result in the configure check
using C++ instead of C.
  2.  Run ./autogen.sh and './configure --with-kernel-support'.
  3.  Look at the config.log and note the results of both
bfd_openr_iovec tests.  My guess is the first check will fail, so the
second one won't even be attempted.  If this is the case, it means your
gcc and g++ are not using the same BFD library for some reason.
  4.  Run 'make'.  It should compile this time, but I don't think this
is going to *fix* your problem.

-Maynard
>>   each function it appears in.)
>> make[3]: *** [bfd_spu_support.o] Error 1
>> make[3]: Leaving directory `/usr/src/aslan/oprofile/oprofile-0.9.3/libutil++'
>>
>> Therefore after configure, I manually undefined the
>> HAVE_BFD_OPENR_IOVEC_WITH_7PARMS in config.h, because I don't care
>> "SPU" at all.
>> /* Defined if you have the version of bfd_openr_iovec with 7 parameters */
>> #undef HAVE_BFD_OPENR_IOVEC_WITH_7PARMS
>>
>> Could this be the reason to cause segmentation fault at run time? If
>> so how could I fix it?
>>
>> Thanks.
>>
>> - Reeve
>>
>> On Fri, May 9, 2008 at 10:52 AM, Dave Nomura <dc...@us...> wrote:
>>     
>>> csh/tcsh: limit stacksize unlimited, bash: ulimit -s unlimited
>>>
>>> Reeve Yang wrote:
>>>       
>>>> Hi Dave, how may I check/change the stack size of shell? Thanks!
>>>>
>>>> On Fri, May 9, 2008 at 8:04 AM, Dave Nomura <dc...@us...> wrote:
>>>>
>>>>         
>>>>> You might try setting your maximum stack size to unlimited in your shell.
>>>>> (bash: ulimit, csh: limit)
>>>>> Oprofile, samples everything that is running on your system at the time.
>>>>>  I
>>>>> am looking into a different problem whose symptoms are segfault, and
>>>>> caused
>>>>> by a very large object being allocated on the stack.
>>>>> Reeve Yang wrote:
>>>>>
>>>>>           
>>>>>> Hi guys,
>>>>>>
>>>>>> I'm running oprofile 0.9.3 on kernel 2.6.22. My CPUs are P4 or Xeon
>>>>>> dual core. But no matter what, opcontrol works fine and I can sample
>>>>>> the kernel, and I can use opreport to get overall report. While using
>>>>>> "opreport -l -p ... vmlinux", I got segmentation fault. Is this a
>>>>>> known problem? Can anyone help me fix it 'cause I really don't have
>>>>>> time to debug into oprofile source code.
>>>>>>
>>>>>> Thanks a lot.
>>>>>> - Reeve
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't
>>>>>> miss this year's exciting event. There's still time to save $100. Use
>>>>>> priority code J8TL2D2.
>>>>>>
>>>>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>>>>> _______________________________________________
>>>>>> oprofile-list mailing list
>>>>>> opr...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>>>>>>
>>>>>>
>>>>>>             
>>>>> --
>>>>> Dave Nomura
>>>>> LTC Linux Power Toolchain
>>>>>
>>>>>
>>>>>
>>>>>           
>>> --
>>> Dave Nomura
>>> LTC Linux Power Toolchain
>>>
>>>
>>>       
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> oprofile-list mailing list
> opr...@li...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>