Anyone running check or rcunit?

Post #327,864 by scoenye 6/12/10 1:16:18 AM Reply	Anyone running check or rcunit? I'm trying to strap a unit testing framework to a C project but the two above crash inside the framework with an access violation segfault in strcpy. Check 0.9.8 crashes on a straight strcpy call, rcunit crashes via a sprintf call. This happens as soon as the framework is engaged. It does not depend on the presence of any tests. Compiler and OS are gcc 4.3 on Debian amd64 with libc6 2.11.1. Recompiling the unit test frameworks and project from scratch does not fix the issue, nor does using gcc 3.4. No errors occur during the compile, and -Wall -Wextra only turn up a handful of unused parameters. A gdb session on rcunit didn't run up anything out of the ordinary until the crash. It allocates a 32 byte block, succesfully completes a memset call to zero the contents, and then crashes when it tries to sprintf the output of ctime() [26 bytes total]. Problem is that even with libc6-dbg and the libc6 sources installed, I can't step through the strcpy call. Valgrind doesn't provide any better insight either. I tried check and rcunit because they are C based, not C++, and both work with automake as well as the Eclipse CDT. Next step will be to locate a box which still has Lenny's glibc on it. If anyone has either running succesfully, any recollections of special tricks needed to get these going?
Post #327,867 by static 6/12/10 8:49:18 AM Reply	Trying turning optimizations off? I had that problem with compiling Unicon on AMD64 under Ubuntu. There were initially a lot of errors that the maintainter thought had been shaken out (Unicon's been 64-bit possible for some years) suggesting a lot of strictness for some reason. Compiling without optimizations also fixed a segfault even he had trouble finding. Wade. Q:Is it proper to eat cheeseburgers with your fingers? A:No, the fingers should be eaten separately.
Post #327,890 by scoenye 6/12/10 11:31:01 PM Reply	To no avail I had to turn optimization off to just to be able to use GDB. Recompiling both the framework and the project with -O0 made no difference.
Post #328,004 by scoenye 6/14/10 11:15:48 PM 6/14/10 11:18:07 PM Reply	strcpy doesn't like ctime()... `#include <stdio.h> #include <stdlib.h> #include <time.h> #define BUFFER_SIZE 40 int main(void) { time_t t; char array_buffer[BUFFER_SIZE]; char *ctime_buffer; time(&t); ctime_buffer = ctime(&t); snprintf(array_buffer, BUFFER_SIZE, ctime_buffer); printf("Current time in array_buffer: %s", array_buffer); sprintf(array_buffer, "%s", ctime_buffer); // segfault printf("Current time in array_buffer: %s", array_buffer); return EXIT_SUCCESS; }` The above is a redux of the rcunit crash. For some reason, the output of ctime() causes the crash if the bounds aren't checked. It does not matter how large the buffer is. If the "%s" in the faulting statement is changed to "%.26s" (or if "%s" is simply omitted), then the crash no longer occurs. The implication is that ctime() does not return a 0 terminated string, but it does. I had a check loop in between the two sections, and the 0 is exactly where it needs to be, at byte 26. The catch is that the crashing statement results in `sprintf(array_buffer, "%s", ctime(&t)); <main+30>: lea -0x10(%rbp),%rdi <main+34>: callq 0x400478 <ctime@plt> <main+39>: mov %rax,%rsi <main+42>: lea -0x40(%rbp),%rdi <main+46>: callq 0x600a00 <strcpy@@GLIBC_2.2.5>` while the other forms result in `sprintf(array_buffer, "%.26s", ctime(&t)); <main+30>: lea -0x10(%rbp),%rdi <main+34>: callq 0x400468 <ctime@plt> <main+39>: lea -0x40(%rbp),%rdi <main+43>: mov %rax,%rdx <main+46>: mov $0x400700,%esi <main+51>: mov $0x0,%eax <main+56>: callq 0x400498 <sprintf@plt>` So even with -O0, the first case degenerates to a strcpy() call. Which means all the crashes are caused by strcpy() (already knew that was the case with check.) At least it looks like there is a way around it, but this is just plain weird... Edited by scoenye June 14, 2010, 11:18:07 PM EDT Expand All History
Post #328,369 by scoenye 6/21/10 10:40:54 PM Reply	Debian binutils guilty See http://bugs.debian.o...rt.cgi?bug=585051 The Lenny binutils somehow ends up loading incomplete versions of some optimized functions at runtime. The strcpy() that caused my initial problem was cut in half. Binutils is not a dependency of eglibc, so did not get upgraded when the letter went to unstable. An upgrade to the unstable version now fixes the problem. Back to real work...
Post #328,371 by Another Scott 6/21/10 10:59:19 PM Reply	Glad you got it figured out!

Welcome to IWETHEY!