Bug #1533
closed
function 'strncmp' from libc have periodicly core dump
50%
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
Updated by Yuri Pankov over 11 years ago
Is there any reproducible test case for this?
Updated by Igor Kozhukhov over 11 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
Updated by Gary Mills over 11 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.
Updated by Igor Kozhukhov over 11 years ago
I think we have to update our libc - why we have core dump instead of 'WARNING' or "ERROR" message?
Updated by Yuri Pankov over 11 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.
Updated by Igor Kozhukhov over 11 years ago
We have our own LIBC and we can do it better.
Updated by Jason King over 11 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.
Updated by Alex Viskovatoff over 11 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.
Updated by Alex Viskovatoff over 11 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.
Updated by Rich Lowe over 11 years ago
- Status changed from Feedback to Rejected
- Assignee deleted (
Jason King) - Tags deleted (
needs-triage)