SIGSEGV, SEGV_MAPERR - Address not mapped to object

[Pinkerik]

Again I run into problem, where I have tryed everything I know, but still can't resolve this..

Getting SEGV_MAPERR in destructor of std::string class, which is allocated on stack

from $sp diff I suspect it's thread stack overflow, but I'm using 16MB as stack size there ...

[Dennis Handly]

>from $sp diff I suspect it's thread stack overflow,

>(gdb) p $sp - $sp_save $1 = 1968

No, that's trivially small.

gr32: 0x181978

0x9fffffffbf3e3c20:0 <__pthread_mutex_destroy_ng+0x80>: (p1) ld2 r23=[r32]

You have a corrupted pointer.  Possibly writing beyond the bounds of a heap object and blasting this mutex pointer.

You could use gdb's heap-check option to catch this.

What does this show?

(gdb) frame 4

(gdb) p *this

(gdb) x /s *(char**)this

(gdb) x /16gx *(char**)this-8*8

[Pinkerik]

(gdb) f 4
#4  0x9fffffffb97a2b80:0 in std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string (this=0x9fffffffb84d0890)
    at /opt/aCC/include_std/string:361
361             _C_unlink();
(gdb) p *this
$2 = {
  _C_data = 0x60000000004f8240 "insert into sym_xv_gl_acct_dwh (id$,msg_id$,ref_id$,type_code$,rec_version$,accrued_bal, acct_close_date, acct_close_reason, acct_desc, acct_no,acct_open_date, acct_status, acct_type, actual_agg_bal_c"..., 
  static __nullref = <optimized out>, static npos = <optimized out>}
(gdb) x /s *(char**)this
0x60000000004f8240:      "insert into sym_xv_gl_acct_dwh (id$,msg_id$,ref_id$,type_code$,rec_version$,accrued_bal, acct_close_date, acct_close_reason, acct_desc, acct_no,acct_open_date, acct_status, acct_type, actual_agg_bal_c"...
(gdb) x /16gx *(char**)this-8*8
0x60000000004f8200:     0x6000000000120150      0x0000000000000581
0x60000000004f8210:     0x000000000f0fff01      0x0000000000000000
0x60000000004f8220:     0x0000000000181978      0xffffffffffffffff
0x60000000004f8230:     0x0000000000000532      0x0000000000000532
0x60000000004f8240:     0x696e736572742069      0x6e746f2073796d5f
0x60000000004f8250:     0x78765f676c5f6163      0x63745f6477682028
0x60000000004f8260:     0x6964242c6d73675f      0x6964242c7265665f
0x60000000004f8270:     0x6964242c74797065      0x5f636f6465242c72

I already tryed running gdb with set heap-check bounds/leaks on, but it craches at the same place

but it has one more frame in backtrace

#2 0x9fffffffbf6e2240:0 in __rtc_pthread_mutex_destroy (mutex=<not available>)
at ../../../Src/gnu/gdb/thread_event/analysis.c:166

[Dennis Handly]

(gdb) x /16gx *(char**)this-8*8

0x60000000004f8200: 0x6000000000120150 0x0000000000000581

0x60000000004f8210: 0x000000000f0fff01 0x0000000000000000

0x60000000004f8220: 0x0000000000181978 0xffffffffffffffff

The high byte of 0x60000000004f8210 is being blasted.  It probably should be 0x60 to match the other data addresses.

I think 0x6000000000120150 is the heap region back link and 0x0000000000000581 is the length of the current region.

>I already tryed running gdb with set heap-check bounds/leaks on

What did "show heap-check" show?

[Pinkerik]

(gdb) show heap-check
Current heap check settings are :
        Check leaks      : on
        Check bounds     : on
        Check free()     : off
        Check string     : off
        Scrambling       : off
        Frame count      : 4
        Min-leak-size    : 0
        Min-heap-size    : 0
        Block-size       : 0
        Header-size      : 16
        Footer-size      : 1
        Seed-value       : 5
        Random-range     : 100
        Null-check       : -1
        Null-check-size  : -1
        Heap-size        : 0
        Heap Interval    : 0
        Repeat Count     : 100
        High-mem Count   : 0
        Watch Address    : 0x00000000
        retain-freed-blocks : off

Tryed to debug it command by command

[Switching to thread 5 (system thread 3895793)]

Breakpoint 1, OciConnection::ParseStatement (this=0x6000000001360090, 
    statement=0x600000000136ae90, error=0x9fffffff5df30b20)
    at /home/clag/projects/tomas/oci_wrapper/src/oci_connection.cc:292
292       std::string stmt_str(statement->stmt_str());
(gdb) 
(gdb) n
293       std::string bind_name;
(gdb) x /16gx *(char**)&stmt_str-8*8
0x600000000128b5d0:     0x000000000f0fff00      0x0000000000000000
0x600000000128b5e0:     0xfeedfacefeedface      0xfeedfacefeedface
0x600000000128b5f0:     0x6000000000023d08      0x0000000000000003
0x600000000128b600:     0x00000000000003bb      0x00000000000003bb
0x600000000128b610:     0x73656c6563742061      0x6363727565645f62
0x600000000128b620:     0x616c2c2061636374      0x5f636c6f73655f64
0x600000000128b630:     0x6174652c20616363      0x745f636c6f73655f
0x600000000128b640:     0x726561736f6e2c20      0x616363745f646573
(gdb) n
295       std::transform(stmt_str.begin(), stmt_str.end(), stmt_str.begin(), ::tolower);
(gdb) 
297       size_t pos = 0, end_pos;
(gdb) 
299       if (statement->type() == OciStatement::EXPORT) {
(gdb) 
300         while ((end_pos = stmt_str.find_first_of(":\'", pos)) != std::string::npos) {
(gdb)  
421       return *error;
(gdb) 
0x9fffffffb96e8ce0:0    421       return *error;
(gdb) 
0x9fffffffb96e8d10:0    421       return *error;
(gdb) 

Program received signal SIGSEGV, Segmentation fault
  si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x9fffffffbf2f7c20:0 in __pthread_mutex_destroy_ng+0x80 ()
   from /usr/lib/hpux64/libpthread.so.1
(gdb) f 5
#5  0x9fffffffb96b2b80:0 in std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string (this=0x9fffffff5df30890)
    at /opt/aCC/include_std/string:361
361             _C_unlink();
(gdb) x /16gx *(char**)this-8*8     
0x60000000015f4b90:     0x000000000f0fff04      0x0000000000000000
0x60000000015f4ba0:     0xfeedfacefeedface      0xfeedfacefeedface
0x60000000015f4bb0:     0x000000000137e428      0xffffffffffffffff
0x60000000015f4bc0:     0x00000000000003bb      0x00000000000003bb
0x60000000015f4bd0:     0x73656c6563742061      0x6363727565645f62
0x60000000015f4be0:     0x616c2c2061636374      0x5f636c6f73655f64
0x60000000015f4bf0:     0x6174652c20616363      0x745f636c6f73655f
0x60000000015f4c00:     0x726561736f6e2c20      0x616363745f646573
(gdb) print *this
$1 = {
  _C_data = 0x60000000015f4bd0 "select accrued_bal, acct_close_date, acct_close_reason, acct_desc, acct_no,acct_open_date, acct_status, acct_type, actual_agg_bal_ctd, actual_agg_bal_mtd,actual_agg_bal_ytd, actual_bal, actual_bal_o, "..., 
  static __nullref = <optimized out>, static npos = <optimized out>}

 And just in those few commands it crashes

Now I'm completely lost

inline const std::string &stmt_str() const { return stmt_str_; }

[Pinkerik · Accepted solution]

Found out what the problem was,

thing is that the library in which the call crashed (OciConnection::ParseStatement) wasn't compiled with -mt flag, while the main program was

I tryed to replace 

std::string stmt_str(statement->stmt_str());

with

const std::string &stmt_str(statement->stmt_str());

and after it went through the function, and started to crash with new error message:

aCC runtime: Use of "-mt" must be consistent during both compilation and linking

After that I've used /usr/ccs/bin/footprints to check that, recompile my other libs and everything is ok now

Now I could have return to

std::string stmt_str(statement->stmt_str());

and everything works fine 

Thank you for help, and sorry for taking your time

[Dennis Handly]

>(gdb) show heap-check

>Check free() : off

>Check string : off

You may want to turn these on next time.

>And just in those few commands it crashes

You could single step instructions with "si".  And if the address is the same, you could set a watchpoint on that address.

0x60000000015f4bb0: 0x000000000137e42

>wasn't compiled with -mt flag, while the main program was ... and everything works fine

Great news.