Project

General

Profile

Bug #1533

function 'strncmp' from libc have periodicly core dump

Added by Igor Kozhukhov almost 8 years ago. Updated almost 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-09-18
Due date:
% Done:

50%

Estimated time:
Difficulty:
Medium
Tags:

Description

I have often core dumps

Loading modules: [ libc.so.1 ld.so.1 ]

$C

080479d8 libc.so.1`strncmp+0x17(0, 80796bd, 8047a18, 80a6900)
08047a08 add_prefix+0x3d(80a04cc, 0, 80796bd, 1, 0, 0)
08047b08 process_command+0x5f6(9, 8047c40, 39, 8063def)
08047c08 main+0xacc(80754da, feffbafc, 8047c34, 8058bd7, 9, 8047c40)
08047c34 _start+0x83(9, 8047d14, 8047d4d, 8047d84, 8047dac, 8047dd4)

With truss:
root@srv243:/myshare/builds/dilos/gcc/gcc-4.4-4.4.5# truss /myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/./gcc/xgcc -B/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/./gcc/ -B/usr/gcc/4.4/i386-pc-solaris2.11/bin/ -B/usr/gcc/4.4/i386-pc-solaris2.11/lib/ -isystem /usr/gcc/4.4/i386-pc-solaris2.11/include -isystem /usr/gcc/4.4/i386-pc-solaris2.11/sys-include -dumpspecs
execve("/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/gcc/xgcc", 0x08047C24, 0x08047C4C) argc = 9
sysinfo(SI_MACHINE, "i86pc", 257) = 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000
brk(0x080B9A08) = 0
llseek(3, 0, SEEK_CUR) = 29504
close(3) = 0
open("/usr/lib/locale//en_US.UTF-8/LC_MESSAGES/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047960) = 0
read(3, " ^ ( ( [ y Y ] ( [ e E ]".., 45) = 45
close(3) = 0
open("/usr/gcc/4.4/share/locale/en_US.UTF-8/LC_MESSAGES/gcc-4.4.mo", O_RDONLY) Err#2 ENOENT
schedctl() = 0xFEDE4000
sigaction(SIGINT, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGINT, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGHUP, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGHUP, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGTERM, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGTERM, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGPIPE, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGPIPE, 0x08047A30, 0x08047AB0) = 0
sigaction(SIGCLD, 0x08047A30, 0x08047AB0) = 0
resolvepath("/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/./gcc/xgcc", "/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/gcc/xgcc", 1024) = 54
resolvepath("/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/./gcc/xgcc", "/myshare/builds/dilos/gcc/gcc-4.4-4.4.5/build/gcc/xgcc", 1024) = 54
Incurred fault #6, FLTBOUNDS %pc = 0xFEE42407
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000

History

#1

Updated by Yuri Pankov almost 8 years ago

Is there any reproducible test case for this?

#2

Updated by Igor Kozhukhov almost 8 years ago

for reproduce you can add flag: --enable-clocale=gnu - to GCC4 build
I know that it is mistake - but it is flag enable core dump

#3

Updated by Gary Mills almost 8 years ago

You are passing a null string as the first argument:

080479d8 libc.so.1`strncmp+0x17(0, 80796bd, 8047a18, 80a6900)

It should be:

int strncmp(const char *s1, const char *s2, size_t n);

You have a bug in your software.

#4

Updated by Igor Kozhukhov almost 8 years ago

I think we have to update our libc - why we have core dump instead of 'WARNING' or "ERROR" message?

#5

Updated by Gary Mills almost 8 years ago

`null pointer', I meant.

#6

Updated by Yuri Pankov almost 8 years ago

Igor S.Kozhukhov wrote:

I think we have to update our libc - why we have core dump instead of 'WARNING' or "ERROR" message?

It isn't our libc problem - strncmp on linux(GLIBC) segfaults in the same way when given NULL pointer.

#7

Updated by Igor Kozhukhov almost 8 years ago

We have our own LIBC and we can do it better.

#8

Updated by Jason King almost 8 years ago

None of the str* functions accept NULL arguments as far as I know. This would be a rather surprising change. The stack trace strongly suggests an application error in the invocation of strncmp. To allow the application to continue in the face of such an error is likely to produce strange and wrong results. I think the correct thing here is to fix the application.

#9

Updated by Alex Viskovatoff almost 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Jason King
  • % Done changed from 0 to 50

Igor S.Kozhukhov wrote:

I think we have to update our libc - why we have core dump instead of 'WARNING' or "ERROR" message?

Because the C standard does not specify that the compiler needs to add runtime error checking to binaries behind the scenes? It's simply not that kind of language.

#10

Updated by Alex Viskovatoff almost 8 years ago

What I should have said is that the strncmp man page states that "The arguments s, s1, and s2 point to strings". Thus, if a null pointer is passed as one of the arguments, the function is not being used correctly, which means that there is a bug in your program.

What you're asking for here is a radical reworking of what is involved in writing a C program. One reason programs written in C are fast is that C libraries do not do incessant runtime error checking of the kind you are proposing.

#11

Updated by Rich Lowe almost 8 years ago

  • Status changed from Feedback to Rejected
  • Assignee deleted (Jason King)
  • Tags deleted (needs-triage)

Also available in: Atom PDF