* [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
@ 2004-01-02 2:52 Michael Torrie
2004-01-02 3:26 ` J. Mayer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Torrie @ 2004-01-02 2:52 UTC (permalink / raw)
To: qemu-devel
I'm still having many problems using qemu to run all but the most basic
static-ish x86 executables on my yellowdog ppc box. qemu just dies with
a segmentation fault. I can run xterm, xeyes, ddd, and adobe acrobat
reader, all from my x86 fedora core box (copying over the appropriate
libraries for glibc, x11, etc). However, most other exes, even a simple
exe like ls, fail with the segmentation fault. Since no one else is
reporting this problem on the list, I think that perhaps it is an
interaction between qemu and the ntpl-threaded glibc 2.3.3 that fedora
core ships with.
To replicate the problem, copy over ls and any dependent libraries to
the yellowdog 3.0.1 box. run ls with qemu 0.51. qemu will quit with a
segmentation fault. Doing some simple debugging indicates that there is
a null pointer that is dereferenced somewhere in the synthetic cpu
code. See my other posts from last month for the exact place in the
code; I don't have the capabilities to debug qemu until I return from
vacation.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
2004-01-02 2:52 [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls Michael Torrie
@ 2004-01-02 3:26 ` J. Mayer
2004-01-02 4:47 ` Michael Torrie
0 siblings, 1 reply; 6+ messages in thread
From: J. Mayer @ 2004-01-02 3:26 UTC (permalink / raw)
To: qemu-devel
On Fri, 2004-01-02 at 03:52, Michael Torrie wrote:
> I'm still having many problems using qemu to run all but the most basic
> static-ish x86 executables on my yellowdog ppc box. qemu just dies with
> a segmentation fault. I can run xterm, xeyes, ddd, and adobe acrobat
> reader, all from my x86 fedora core box (copying over the appropriate
> libraries for glibc, x11, etc). However, most other exes, even a simple
> exe like ls, fail with the segmentation fault. Since no one else is
> reporting this problem on the list, I think that perhaps it is an
> interaction between qemu and the ntpl-threaded glibc 2.3.3 that fedora
> core ships with.
You're right, this is the right explanation.
I've already seen this problem, but didn't solve it, with a recent
Debian using glibc 2.3...
The glibc 2.3 signal context structure isn't the same that the one used
in glibc 2.2. This makes qemu think that the emulated program is doing
invalid access while it should detect some valid write access to code
pages.
I'm surprised that you were able to compile qemu with this glibc. When I
tried to use glibc 2.3 on PPC, qemu failed to compile, because the
structure field names also changed. Are your headers fully synchronised
with your libc ?
I don't believe it's a thread-scheme problem, because qemu don't use
threads. Or it may be some other glibc definitions or structure padding
or alignment which aren't the same than in the regular glibc...
Regards.
--
J. Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
2004-01-02 3:26 ` J. Mayer
@ 2004-01-02 4:47 ` Michael Torrie
2004-01-02 13:14 ` J. Mayer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Torrie @ 2004-01-02 4:47 UTC (permalink / raw)
To: qemu-devel
On Thu, 2004-01-01 at 20:26, J. Mayer wrote:
> You're right, this is the right explanation.
> I've already seen this problem, but didn't solve it, with a recent
> Debian using glibc 2.3...
> The glibc 2.3 signal context structure isn't the same that the one used
> in glibc 2.2. This makes qemu think that the emulated program is doing
> invalid access while it should detect some valid write access to code
> pages.
>
> I'm surprised that you were able to compile qemu with this glibc. When I
> tried to use glibc 2.3 on PPC, qemu failed to compile, because the
> structure field names also changed. Are your headers fully synchronised
> with your libc ?
qemu was compiled on my yellowdog ppc box, which doesn't use the nptl
glibc-2.3.3. I think it's still glibc-2.3.1, without nptl.
> I don't believe it's a thread-scheme problem, because qemu don't use
> threads. Or it may be some other glibc definitions or structure padding
> or alignment which aren't the same than in the regular glibc...
I guess I'll have to try downloading a non-nptl x86 glibc and try that.
But it would be nice to figure out how to get the nptl glibc working
with qemu (even in non-nptl mode, since nptl would depend on the kernel
support).
Since many of the exe's I'd be wanting to run depend on GLIBC_2.3, I
could compile a special version of glibc that doesn't use nptl. Would
that work? Or are there still internal changes that would prohibit this
right now?
Michael
>
> Regards.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
2004-01-02 4:47 ` Michael Torrie
@ 2004-01-02 13:14 ` J. Mayer
2004-01-02 22:19 ` Michael Torrie
0 siblings, 1 reply; 6+ messages in thread
From: J. Mayer @ 2004-01-02 13:14 UTC (permalink / raw)
To: qemu-devel
On Fri, 2004-01-02 at 05:47, Michael Torrie wrote:
> On Thu, 2004-01-01 at 20:26, J. Mayer wrote:
> > You're right, this is the right explanation.
> > I've already seen this problem, but didn't solve it, with a recent
> > Debian using glibc 2.3...
> > The glibc 2.3 signal context structure isn't the same that the one used
> > in glibc 2.2. This makes qemu think that the emulated program is doing
> > invalid access while it should detect some valid write access to code
> > pages.
> >
> > I'm surprised that you were able to compile qemu with this glibc. When I
> > tried to use glibc 2.3 on PPC, qemu failed to compile, because the
> > structure field names also changed. Are your headers fully synchronised
> > with your libc ?
>
> qemu was compiled on my yellowdog ppc box, which doesn't use the nptl
> glibc-2.3.3. I think it's still glibc-2.3.1, without nptl.
May the changes has been made between glibc 2.3.1 and following versions
? Strange idea... I have to check this...
> > I don't believe it's a thread-scheme problem, because qemu don't use
> > threads. Or it may be some other glibc definitions or structure padding
> > or alignment which aren't the same than in the regular glibc...
>
> I guess I'll have to try downloading a non-nptl x86 glibc and try that.
> But it would be nice to figure out how to get the nptl glibc working
> with qemu (even in non-nptl mode, since nptl would depend on the kernel
> support).
Well, you may rebuild qemu as a static binary on your yellowdog
distribution. If it compiles without a problem, you'll win :-)
It seems really more simple than trying to make two glibc available on
your system...
--
J. Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
2004-01-02 13:14 ` J. Mayer
@ 2004-01-02 22:19 ` Michael Torrie
2004-01-03 0:23 ` J. Mayer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Torrie @ 2004-01-02 22:19 UTC (permalink / raw)
To: qemu-devel
On Fri, 2004-01-02 at 06:14, J. Mayer wrote:
> Well, you may rebuild qemu as a static binary on your yellowdog
> distribution. If it compiles without a problem, you'll win :-)
> It seems really more simple than trying to make two glibc available on
> your system...
What does this have to do with my problem of qemu segfaulting when I run
x86 binaries? qemu builds and runs just fine. So that's not the
problem. It already compiles. Making qemu static will not help my
problem with glibc (remember it's the x86 glibc that's causing the
problems, not the ppc version). This is a bug in how qemu interacts
with the x86 glibc (in the gnemul folder). Not saying that it's not
related to the ppc glibc; just that what you're telling me doesn't seem
to fit with my problem.
To recap, xeyes, xterm, ddd, acrobat reader all work under qemu. I
copied them straight off my fedora core box. on my ppc yellowdog box,
qemu can run them just fine. Even a simple hello world that I compiled
works. However most other binaries cause qemu to segfault with a null
pointer problem, caused most likely by an interaction between qemu and
the x86 glibc stored in the /usr/gnemul folder.
Michael
Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
2004-01-02 22:19 ` Michael Torrie
@ 2004-01-03 0:23 ` J. Mayer
0 siblings, 0 replies; 6+ messages in thread
From: J. Mayer @ 2004-01-03 0:23 UTC (permalink / raw)
To: qemu-devel
On Fri, 2004-01-02 at 23:19, Michael Torrie wrote:
> On Fri, 2004-01-02 at 06:14, J. Mayer wrote:
> > Well, you may rebuild qemu as a static binary on your yellowdog
> > distribution. If it compiles without a problem, you'll win :-)
> > It seems really more simple than trying to make two glibc available on
> > your system...
>
> What does this have to do with my problem of qemu segfaulting when I run
> x86 binaries? qemu builds and runs just fine. So that's not the
> problem. It already compiles. Making qemu static will not help my
> problem with glibc (remember it's the x86 glibc that's causing the
> problems, not the ppc version).
Ooops, I misunderstood you. I had some problems with the host glibc on
PPC . So, you're rigth, you may try with a non non-nptl x86 glibc.
Sorry for this mistake...
--
J. Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-03 1:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-02 2:52 [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls Michael Torrie
2004-01-02 3:26 ` J. Mayer
2004-01-02 4:47 ` Michael Torrie
2004-01-02 13:14 ` J. Mayer
2004-01-02 22:19 ` Michael Torrie
2004-01-03 0:23 ` J. Mayer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).