Core in libc.so.1

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

Answers


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...

)


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.


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.


Need Your Help

Using EclipseLink JPA to bind Strings larger than 255 characters

java sql jpa eclipselink

I inherited a project which uses EclipseLink JPA to persist objects into any SQL database. Currently it comes with a local Derby DB distribution. During some tests I found out that the program will...