Core in libc.so.1

Question

I am using Solaris 10 and my C program is getting crashed and creates a core file. On debugging, it seems like the core is created in libc.so.1. Please let me know if anyone have any clue. Below is the dbx report.

dbx prock.new core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading prock.new
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libl.so.1
Reading libpthread.so.1
Reading librt.so.1
Reading libthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libc_psr.so.1
WARNING!!
A loadobject was found with an unexpected checksum value.
See `help core mismatch' for details, and run `proc -map'
to see what checksum values were expected and found.
dbx: warning: Some symbolic information might be incorrect.
t@null (l@1) terminated by signal SEGV (no mapping at the fault address)
0xffffffff7ea3bc14: strcasecmp+0x0134:  orn      %i0, %i3, %i0
(dbx) where
=>[1] strcasecmp(0x10014b68e, 0x57, 0x7ffffc00, 0x1001332d7, 0x27, 0x24), at 0xffffffff7ea3bc14
  [2] 0x10000af48(0x27, 0x10014b68e, 0x57, 0x10014b68e, 0x57, 0x0), at 0x10000af48
  [3] 0x100009c08(0x27, 0x5e, 0x0, 0x9, 0x1001332c3, 0x2b), at 0x100009c08

(dbx) whereis strcasecmp
function:       `libc.so.1`strcasecmp
(dbx)

My solaris version is

               Solaris 10 8/07 s10s_u4wos_12b SPARC
   Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                Use is subject to license terms.
                    Assembled 16 August 2007

Looks like the arguments being passed by you to strcasecmp are improper (either corrupted or strings are not NULL terminated etc) — Jay, Aug 01 '12 at 13:52

score 2 · Answer 1 · answered Aug 01 '12 at 13:52

2

No, the problem is not with the C standard library. You're passing an invalid parameter (NULL string pointer, etc.) to strcasecmp(). Without actual code (which you haven't posted), it's not possible to deduce what exactly the error is.

(Also, you better compile your program with debug symbols - with optimization turned off! If you're on Solaris, you most probably use GCC:

gcc -O0 -g etc...

)

answered Aug 01 '12 at 13:52

Yes, this is my viewpoint too. There should not be a problem with C library. – Sachin Aug 01 '12 at 14:02

score 1 · Answer 2 · edited Aug 02 '12 at 06:58

1) Compile your program to include debug information (add "-g" to the list of options to your compiler), so that you actually get information instead of this:

 [2] 0x10000af48(0x27, 0x10014b68e, 0x57, 0x10014b68e, 0x57, 0x0), at 0x10000af48
 [3] 0x100009c08(0x27, 0x5e, 0x0, 0x9, 0x1001332c3, 0x2b), at 0x100009c08

2) DBX will now tell you which of your functions has been calling strcasecmp. Step through the source (or have it generate log output), check the parameters of the fatal function call for anything out of the ordinary (like invalid pointers).

The chances of you discovering a bug in a libc function are infinitesimal compared to the chances that your call to that function was in error.

Thanks DevSolar, I will add some more debugging options and will be back. — Sachin, Aug 01 '12 at 14:05

score 0 · Answer 3 · answered Aug 01 '12 at 19:16

1) Run bt (backtrace) to see who is calling strcasecmp [ this will list frames like #0, #1 ]

2) Now jump in to the specific frame to get the values [ frame 0 ]

3) Then display / print the value of the argument passed to strcasecmp ( using print or display)

I feel the argument is NULL on calling strcasecmp and that's why you are getting segfault.

Core in libc.so.1

3 Answers3