The latest slirp commits in QEMU git master (commits
953e7f54e679cd40fff28e29189ed9e24bfb0758,
e3078bf40a33b59fa11d077b1d0bb8796470982e,
f37343197708d90f119007ce5ecc2503be9c04c1,
a68adc220603baffc355ecea8865b3ea9707ab00) fixed this issue.
** Changed in: qemu
Status: New => Fix Released
--
This issue appears to be resolved in the *real* current git master, so
this bug can be closed. Now it's just a matter of getting rid of or
updating that mirror.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
Is the GitHub mirror (http://wiki.qemu.org/Download) no long being
updated? It looks like it might not be given the last commit, so it
should really be fixed or removed from that download page and the mirror
deleted.
I used the GitHub mirror because when I tried to clone
git://git.qemu.org/qemu.gi
> Thread 1 (Thread 0xb63d36e0 (LWP 32412)):
> #0 0xb7679517 in slirp_remque (a=0xb9119cf0) at slirp/misc.c:39
> element = 0xb9119cf0
> #1 0xb7677489 in if_start (slirp=0xb87a6eb8) at slirp/if.c:189
> now = 118754910412798
> requeued = 0
> ifm = 0xb9119cf0
> i
Correction, the bug is still present in qemu-git. It seems to be
slightly harder to trigger, but that might just be luck too. Here's the
crash in qemu master 217bfb445b54db618a30f3a39170bebd9fd9dbf2 .
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb63d36e0 (LWP 32412)
Thanks Jan. I was pulling git master as I saw your comment. When
configured using the same command line and built with the same tools in
the same environment, git master does not appear to crash the way 1.0.1
does. Given that there have been fixes in the area merged between 1.0.1
and master it seem
Please re-test over git head. There were related fixes merged recently.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/938431
Title:
Reproducible crash in slirp_remque (qemu 1.0.1)
Status in QEMU:
Another crash site appears to be:
#0 0xb760f0d0 in ifs_insque (ifm=0xba711478, ifmhead=0x0) at slirp/if.c:16
#1 0xb760f2dd in if_output (so=0xba60db70, ifm=0xba711478) at slirp/if.c:98
#2 0xb7610bb5 in ip_output (so=0xba60db70, m0=0xba711478) at
slirp/ip_output.c:84
#3 0xb761959c in tcp_outp
I have now reproduced the same segfault without the controlling script
by running qemu on the command line and connecting to it with lftp. To
reproduce the fault it appears to be necessary to attempt to connect to
the guest before it is fully booted and ready to accept connections; if
I let it "set
