[csw-maintainers] seg fault and stack size issue?

Daniel Pocock daniel at opencsw.org
Mon May 7 14:51:15 CEST 2012 

Running repro (from reSIProcate) in dbx, I've managed to get a slightly
more detailed stack trace.

I've also tried changing the code, e.g. to skip the module with the
problem.  If I do that, I just get the same segfault later on, with a
similar _smalloc stacktrace.  Therefore, I don't believe it is a fault
in the MessageFilterRule class, it seems to be some general issue with
the stack or memory management.

I've tweaked stack page size with mpss, pmap on the core shows a larger
stack segment, but the exact same problem occurs at the same place in
the code.

The code runs fine on Linux and Windows, although I agree that doesn't
mean the code is perfect.

Can anyone suggest the next step for troubleshooting something like this
on Solaris?

LD_PRELOAD=$LD_PRELOAD:mpss.so.1 \
LD_LIBRARY_PATH=/opt/csw/bdb48/lib/:/opt/csw/lib:/home/daniel/ws/resip-trunk.git/rutil/.libs/:/home/daniel/ws/resip-trunk.git/resip/stack/.libs/:/home/daniel/ws/resip-trunk.git/resip/dum/.libs:/home/daniel/ws/resip-trunk.git/repro/.libs/
\
  MPSSSTACK=4M MPSSHEAP=4M \
  dbx repro/.libs/repro
...
runargs ~/repro1.config
run
...
STACK | 20120507-144519.823 | repro | RESIP:TRANSACTION | 1 |
MessageFilterRule.cxx:21 | Creating empty MessageFilterRule()
t at 1 (l at 1) signal SEGV (access to address exceeded protections) in
_smalloc at 0xfdf56e18
0xfdf56e18: _smalloc+0x00ac:    st       %l7, [%o7]
Current function is std::allocator<resip::MethodTypes>::allocate
  384         void * tmp = _RWSTD_STATIC_CAST(void*,(::operator
new(_RWSTD_STATIC_CAST(size_t,(n)))));
(dbx) where
current thread: t at 1
  [1] _smalloc(0xfeab7ca8, 0x0, 0xd9660, 0xfdf56f94, 0xf227a048,
0xfe03929c), at 0xfdf56e18
  [2] malloc(0x1, 0x1, 0xd95ac, 0xff3d2a04, 0xfe0303d8, 0xfe03a5a0), at
0xfdf56e70
  [3] operator new(0x1, 0xff0f1cf0, 0xff1b6844, 0x15d74, 0xfeeecd10,
0x0), at 0xfeed6fc0
=>[4] std::allocator<resip::MethodTypes>::allocate(this = 0xffbfea8b, n
= 0, _ARG3 = (nil)), line 384 in "memory"
  [5]
std::allocator_interface<std::allocator<resip::MethodTypes>,resip::MethodTypes>::allocate(this
= 0xffbfea8b, n = 0, p = (nil)), line 483 in "memory"
  [6] std::vector<resip::MethodTypes,std::allocator<resip::MethodTypes>
>::vector(this = 0x28c3ec, x = CLASS), line 315 in "vector"
  [7] resip::MessageFilterRule::MessageFilterRule(0x28c3c8, 0xffbfed34,
0xff24ed90, 0x0, 0xff3f4380, 0x0), at 0xff2488c0
  [8]
__rwstd::__construct<resip::MessageFilterRule,resip::MessageFilterRule>(p =
0x28c3c8, value = CLASS), line 181 in "memory"
  [9]
std::allocator_interface<std::allocator<resip::MessageFilterRule>,resip::MessageFilterRule>::construct(this
= 0xffbfec32, p = 0x28c3c8, val = CLASS), line 503 in "memory"
  [10]
std::vector<resip::MessageFilterRule,std::allocator<resip::MessageFilterRule>
>::__insert_aux(this = 0x28c0e4, position = (nil), x = CLASS), line 140
in "vector.cc"
  [11]
std::vector<resip::MessageFilterRule,std::allocator<resip::MessageFilterRule>
>::push_back(this = 0x28c0e4, x = CLASS), line 473 in "vector"
  [12] resip::TransactionUser::TransactionUser(this = 0x28c020, t =
DoNotRegisterForTransactionTermination, c =
RegisterForConnectionTermination, k = RegisterForKeepAlivePongs), line
23 in "TransactionUser.cxx"
  [13] resip::DialogUsageManager::DialogUsageManager(this = 0x28bff0,
stack = CLASS, createDefaultFeatures = false), line 94 in
"DialogUsageManager.cxx"
  [14] repro::ReproRunner::createDialogUsageManager(this = 0xffbff954),
line 659 in "ReproRunner.cxx"
  [15] repro::ReproRunner::run(this = 0xffbff954, argc = 2, argv =
0xffbffa84), line 204 in "ReproRunner.cxx"
  [16] main(argc = 2, argv = 0xffbffa84), line 107 in "repro.cxx"



On 04/05/12 11:07, Daniel Pocock wrote:
> 
> 
> I should have mentioned this, but I have tried changing the stack size
> with ulimit already, it was 8MB, now 16MB:
> 
> $ ulimit -s
> 16384
> 
> but pmap still shows just 64K of stack
> 
> 
> On 04/05/12 09:47, Daniel Pocock wrote:
>>
>>
>>
>> I'm trying to run the repro process from reSIProcate
>>
>> The startup phase fails with a seg fault
>>
>> I couldn't find a specific fault in the code, even compiling with +w2
>> hasn't suggested anything wrong.  It is just failing to create some
>> vectors in a constructor, and I think the seg fault may be caused by
>> filling the stack.  Can anyone suggest how I increase the stack size or
>> test this problem more thoroughly when building with SunPro tools?
>>
>> pmap reports a 64k stack size:
>>
>> pmap core
>> core 'core' of 23190:
>> /home/daniel/ws/resip-trunk.git/repro/.libs/repro /home/daniel/repro1.
>> 00010000       8K r-x--  /home/daniel/ws/resip-trunk.git/repro/.libs/repro
>> 00020000       8K rwx--  /home/daniel/ws/resip-trunk.git/repro/.libs/repro
>> 00022000      56K rwx--
>> 00030000    2432K rwx--    [ heap ]
>> FD600000    1408K r-x--  /opt/csw/lib/libcrypto.so.0.9.8
>> FD760000      24K r-x--  /opt/csw/lib/libcrypto.so.0.9.8
>> FD774000      88K rwx--  /opt/csw/lib/libcrypto.so.0.9.8
>> FD78A000       8K rwx--  /opt/csw/lib/libcrypto.so.0.9.8
>> FD7C0000      64K rwx--
>> FD7E0000      64K rwx--
>> FD800000    1216K r-x--  /lib/libc.so.1
>>
>> ...
>>
>> FEBB0000     192K r-x--  /lib/ld.so.1
>> FEBE0000      16K r-x--  /lib/ld.so.1
>> FEBF0000       8K rwx--
>> FEBF4000       8K rwx--  /lib/ld.so.1
>> FEBF6000       8K rwx--  /lib/ld.so.1
>> FEBFC000       8K rwx--
>> FFBF0000      64K rwx--    [ stack ]
>>  total     22736K
>>
>>
>>
>> and this is the stack:
>>
>> core 'core' of 23190:
>> /home/daniel/ws/resip-trunk.git/repro/.libs/repro /home/daniel/repro1.
>>  fd856e18 _smalloc (fe2b7ca8, 0, d9660, fd856f94, f227a048, fd93929c) + ac
>>  fd856e70 malloc   (1, 1, d95ac, febd2a04, fd9303d8, fd93a5a0) + 4c
>>  fe356fc0 __1c2n6FI_pv_ (1, 0, 0, 15d74, fe36cd10, 7ffffc00) + 28
>>  fe9b79ec __1cDstdJallocator4nFresipEData__Iallocate6MIpv_3_ (ffbfecab,
>> 0, 0, 20, febf4380, 0) + 2c
>>  fe9b6e48
>> __1cDstdTallocator_interface4n0AJallocator4nFresipEData___n0C__Iallocate6MIpn0C__4_
>> (ffbfecab, 0, 0, 0, febf4380, 0) + 28
>>  fe9b6b1c __1cDstdGvector4nFresipEData_n0AJallocator4n0C____2t5B6Mrk2_v_
>> (ffbfee18, ffbfedac, ffbfedab, ffbfed7d, febf4380, 0) + ac
>>  fdf33d80
>> __1cFresipRMessageFilterRule2t5B6MnDstdGvector4n0AEData_n0CJallocator4n0D_____n0BNHostpartTypes_n0CGvector4n0ALMethodTypes_n0CJallocator4n0H_____3_v_
>> (ffbfede4, ffbfedd4, 0, ffbfedc0, ffbfedac, 0) + 90
>>  fdf35bf8
>> __1cFresipPTransactionUser2t5B6Mn0BWTransactionTermination_n0BVConnectionTermination_n0BOKeepAlivePongs__v_
>> (28be90, 1, 0, 0, fd9303d8, fd93a5a0) + 1a8
>>  fe53bc9c __1cFresipSDialogUsageManager2t5B6Mrn0AISipStack_b_v_ (28be60,
>> 831f0, 0, 15d74, fe36cd10, 28be60) + 7c
>>  fea3ece8 __1cFreproLReproRunnerYcreateDialogUsageManager6M_v_
>> (ffbffa04, ffbff6c0, fdbea248, 0, fdbe461c, ffbff6b8) + 5f0
>>  fea3b2ec __1cFreproLReproRunnerDrun6Mippc_b_ (ffbffa04, 2, ffbffb34,
>> fe356db0, fd7e8cc0, f) + 7c4
>>  00011644 main     (2, ffbffb34, ffbffb40, 21c00, fd7e8c40, 0) + 12c
>>  00011050 _start   (0, 0, 0, 0, 0, 0) + 108
>>
>>
>>
>> and the constructor in question is very minimal, the vectors are created
>> by default argument values:
>>
>> https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/stack/MessageFilterRule.hxx?revision=8707&view=markup
>>
>>
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
> 
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

More information about the maintainers mailing list