Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Sun, Jun 24 2007, Rob Landley wrote: On Saturday 23 June 2007 07:00:03 Jens Axboe wrote: I realize releases are a bit out of fashion, but is there any way to go through cvs to track down which checkin broke this stuff? I can do it in git, mercurial, or subversion. But cvs isn't really set up for this sort of thing... git clone git://git.kernel.dk/data/git/qemu.git and bisect on that then. It's a continued git import of the cvs repo, gets updated every night. Oh _cool_. Any way to get a mention of that on the qemu web page? I don't mind, it's already mentioned on some japanese qemu-win page for quite some time. -- Jens Axboe
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Friday 22 June 2007 19:27:18 andrzej zaborowski wrote: Well it works for me. I usually see this segfault when trying to compile qemu with a gcc4. Try gcc3 and everything should be fine. I usually see this when I forget to rebuild all files affected by a recent change (because the Makefile doesn't make the .depend before you tell it to). I did an rm -rf of the directory and re-downloaded it out from CVS when I first encountered this. Didn't fix it. I just did a make distclean and rebuilt again: same problem. Regards Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Jun 23, 2007, at 7:31 AM, Rob Landley wrote:
On Friday 22 June 2007 19:13:19 Alexander Graf wrote:
Rob Landley wrote:
Ok, it's a more fundamental problem:
[EMAIL PROTECTED]:/sys$ qemu-i386
Segmentation fault (core dumped)
Nothing to do with the program it's trying to run, it segfaults
with no
arguments.
Is anybody else seeing this?
Rob
[EMAIL PROTECTED]:/vm/qemu-devel/patches/qemu qemu-i386 ~/hello
Hello world!
Well it works for me. I usually see this segfault when trying to
compile
qemu with a gcc4. Try gcc3 and everything should be fine.
It's using gcc-3.4. The one that comes with Ubuntu 7.04. (Or at
least ./configure said it had found gcc-3.4 during configuration,
anyway.)
I ran the sucker under strace and it seems to be segfaulting right
before it
calls main(). I stuck an exit(1) at the start of main and it
doesn't get to
it, but it's after all the shared libraries are loaded:
mprotect(0xb7f3f000, 4096, PROT_READ) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_WRITE) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_EXEC) = 0
munmap(0xb7f76000, 57255) = 0
set_tid_address(0xb7deca88) = 4338
sendto(-1210135920, umovestr: Input/output error
0xc, 3084914676,
MSG_DONTWAIT|MSG_CONFIRM|MSG_FIN|MSG_NOSIGNAL|MSG_MORE|0xb7de,
{sa_family=AF_DECnet, sa_data=\0\0\320=\0\0\r\0\0\0p\362\0\0},
3217384328) = 0 rt_sigaction(SIGRTMIN, {0xb7df13f0, [],
SA_SIGINFO}, NULL,
8) = 0
rt_sigaction(SIGRT_1, {0xb7df1300, [], SA_RESTART|SA_SIGINFO},
NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024,
rlim_max=RLIM_INFINITY}) = 0
uname({sys=Linux, node=triolith, ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 4338 detached
If I link int main() {} against -lm and -lrt I get the same set
of calls up
through the first mprotect. (The next two mprotects are probably
setting up
other segments like bss that an empty program doesn't have.) Then
everything
up through the uname() is the same... And then it would call main.
Right now I'm commenting out various global variable
initializations because
that's what comes to mind as stuff that runs right before main().
By the way, by commenting out this bit:
//const char interp[] __attribute__((section(.interp)))
= /lib/ld-linux.so.2;
I made it go from segmentation fault to illegal instruction as
the reason
it dies. Which is weird because there's no non-x86 toolchain the
path, this
is all stock Ubuntu stuff. But oh well...
Alex
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
I guess you're running on i586 then? I only tried this on ppc.
Last time I checked the code-copy stuff was broken, so maybe it helps
to disable that?
If that doesn't work either - would you mind to gdb it and run a bt
when it segfaulted so we can see if the segfault is in the generated
code?
Alex
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Friday 22 June 2007 18:31:20 Rob Landley wrote: Ok, it's a more fundamental problem: [EMAIL PROTECTED]:/sys$ qemu-i386 Segmentation fault (core dumped) Nothing to do with the program it's trying to run, it segfaults with no arguments. Is anybody else seeing this? Rob So I'm vaguely suspecting that some of the dynamic linker magic this thing's doing is contributing to the screw up (or at least the complexity of debugging it), so I thought I'd statically link. If I ./configure --static the result doesn't build, it dies during linking. Is this expected? (Do I need to install .a versions of all the alsa and x11 libraries to make that work?) I realize releases are a bit out of fashion, but is there any way to go through cvs to track down which checkin broke this stuff? I can do it in git, mercurial, or subversion. But cvs isn't really set up for this sort of thing... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
Rob Landley wrote: Ok, it's a more fundamental problem: [EMAIL PROTECTED]:/sys$ qemu-i386 Segmentation fault (core dumped) Nothing to do with the program it's trying to run, it segfaults with no arguments. Is anybody else seeing this? Yes, I get it. Rob -Nigel
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Sat, Jun 23 2007, Rob Landley wrote: On Friday 22 June 2007 18:31:20 Rob Landley wrote: Ok, it's a more fundamental problem: [EMAIL PROTECTED]:/sys$ qemu-i386 Segmentation fault (core dumped) Nothing to do with the program it's trying to run, it segfaults with no arguments. Is anybody else seeing this? Rob So I'm vaguely suspecting that some of the dynamic linker magic this thing's doing is contributing to the screw up (or at least the complexity of debugging it), so I thought I'd statically link. If I ./configure --static the result doesn't build, it dies during linking. Is this expected? (Do I need to install .a versions of all the alsa and x11 libraries to make that work?) I realize releases are a bit out of fashion, but is there any way to go through cvs to track down which checkin broke this stuff? I can do it in git, mercurial, or subversion. But cvs isn't really set up for this sort of thing... git clone git://git.kernel.dk/data/git/qemu.git and bisect on that then. It's a continued git import of the cvs repo, gets updated every night. -- Jens Axboe
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Saturday 23 June 2007 03:27:03 Alexander Graf wrote: I guess you're running on i586 then? Athlon. (/proc/cpuinfo says AMD Sempron(tm) 2200+) I only tried this on ppc. Last time I checked the code-copy stuff was broken, so maybe it helps to disable that? What code-copy stuff? (How do I disable that?) If that doesn't work either - would you mind to gdb it and run a bt when it segfaulted so we can see if the segfault is in the generated code? Sure... except it has no debugging symbols so the backtrace is just numbers and an occasional library name. How about... Huh, ./configure --help doesn't show any sort of --enable-debug... Trying ./configure --extra-cflags=-g... Nope, that stripped it too. Ok, grep for strip and it shows up in multiple places. It's in ./configure but I can't seem to tell configure not to do it. Maybe make STRIP=echo would work? Nope... Grrr: make clean mkdir sub ln /bin/echo sub/strip PATH=`pwd`/sub:$PATH make Ok, that didn't do it either. Would somebody like to clue me in on how to get this darn thing to build a version with debugging symbols, please? In the meantime: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x800773a9 in ?? () #2 0x0001 in ?? () #3 0xbff09304 in ?? () #4 0xbff0930c in ?? () #5 0xb7f75ff4 in ?? () #6 0xb7fc77b0 in ?? () from /lib/ld-linux.so.2 #7 0x80077350 in ?? () #8 0xffee in ?? () #9 0xb7f75ff4 in ?? () #10 0xb7fd3ce0 in ?? () from /lib/ld-linux.so.2 #11 0x80077350 in ?? () #12 0xbff092d8 in ?? () #13 0xb7e4ee61 in ?? () #14 0x0001 in ?? () #15 0xbff09304 in ?? () #16 0xbff0930c in ?? () #17 0xb7fbbdcb in ?? () from /lib/ld-linux.so.2 #18 0x in ?? () Kind of useless... Alex Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
Ok, it's a more fundamental problem: [EMAIL PROTECTED]:/sys$ qemu-i386 Segmentation fault (core dumped) Nothing to do with the program it's trying to run, it segfaults with no arguments. Is anybody else seeing this? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Friday 22 June 2007 19:13:19 Alexander Graf wrote:
Rob Landley wrote:
Ok, it's a more fundamental problem:
[EMAIL PROTECTED]:/sys$ qemu-i386
Segmentation fault (core dumped)
Nothing to do with the program it's trying to run, it segfaults with no
arguments.
Is anybody else seeing this?
Rob
[EMAIL PROTECTED]:/vm/qemu-devel/patches/qemu qemu-i386 ~/hello
Hello world!
Well it works for me. I usually see this segfault when trying to compile
qemu with a gcc4. Try gcc3 and everything should be fine.
It's using gcc-3.4. The one that comes with Ubuntu 7.04. (Or at
least ./configure said it had found gcc-3.4 during configuration, anyway.)
I ran the sucker under strace and it seems to be segfaulting right before it
calls main(). I stuck an exit(1) at the start of main and it doesn't get to
it, but it's after all the shared libraries are loaded:
mprotect(0xb7f3f000, 4096, PROT_READ) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_WRITE) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_EXEC) = 0
munmap(0xb7f76000, 57255) = 0
set_tid_address(0xb7deca88) = 4338
sendto(-1210135920, umovestr: Input/output error
0xc, 3084914676,
MSG_DONTWAIT|MSG_CONFIRM|MSG_FIN|MSG_NOSIGNAL|MSG_MORE|0xb7de,
{sa_family=AF_DECnet, sa_data=\0\0\320=\0\0\r\0\0\0p\362\0\0},
3217384328) = 0 rt_sigaction(SIGRTMIN, {0xb7df13f0, [], SA_SIGINFO}, NULL,
8) = 0
rt_sigaction(SIGRT_1, {0xb7df1300, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys=Linux, node=triolith, ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 4338 detached
If I link int main() {} against -lm and -lrt I get the same set of calls up
through the first mprotect. (The next two mprotects are probably setting up
other segments like bss that an empty program doesn't have.) Then everything
up through the uname() is the same... And then it would call main.
Right now I'm commenting out various global variable initializations because
that's what comes to mind as stuff that runs right before main().
By the way, by commenting out this bit:
//const char interp[] __attribute__((section(.interp)))
= /lib/ld-linux.so.2;
I made it go from segmentation fault to illegal instruction as the reason
it dies. Which is weird because there's no non-x86 toolchain the path, this
is all stock Ubuntu stuff. But oh well...
Alex
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
