malloc scribbles on the stack of newly-compiled programs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc |
Invalid
|
Undecided
|
Unassigned | ||
gdb (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: gcc
After a fresh install of gutsy desktop, I found that programs compiled on it (which would work fine when compiled and run other machines, such as my Intel OS X laptop) would crash with a corrupt stack almost immediately after they began running. (The programs in question were wxWidgets applications, one of my own and one sample "Hello, World!" app for testing.)
The actual stack-scribbling begins the first time the program hits malloc+83 (mov $0x1, %ecx) in libc, but since it only happens to programs I've compiled myself, I'm flagging this as a compiler bug. Note that it happens in both gcc and g++.
Here's the minimal test case:
// Compiled with just "gcc -g -o test test.c"
// gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
// libc 2.6.1-1ubuntu10
// Linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
#include <stdio.h>
#include <stdlib.h>
void wtf(int argc, char** argv) {
// main()'s stack frame gets hosed as soon as the next line executes.
char** myargv = (char**) malloc(
int myargc = argc;
}
int main(int argc, char** argv) {
wtf(argc, argv);
return 0;
}
Debugger output:
(gdb) b wtf
Breakpoint 1 at 0x804837a: file test2.c, line 6.
(gdb) run
Starting program: /home/foo/test2
Breakpoint 1, wtf (argc=1, argv=0xbfdc2f24) at test2.c:6
6 char** myargv = (char**) malloc(
(gdb) bt
#0 wtf (argc=1, argv=0xbfdc2f24) at test2.c:6
#1 0x080483b5 in main (argc=1, argv=0xbfdc2f24) at test2.c:11 [looks OK...]
(gdb) n
7 int myargc = argc;
(gdb) bt
#0 wtf (argc=1, argv=0xbfdc2f24) at test2.c:7
#1 0x080483b5 in main (argc=0, argv=0x20ff1) at test2.c:11 [say what?]
one is enough