[Qemu-devel] linux-user and signal handling

[Qemu-devel] linux-user and signal handling

[Arnaud Patard]

Hi,

When doing some ltp syscall testing with arm-linux-user, some tests are
failing with messages like that :

qemu: uncaught target signal 6 (Aborted) - core dumped
        Child did not return core bit set!
          iteration 0, exit stat = 0x6
        Core = 0, sig = 6, ex = 0
abort01     1  FAIL  :  Test failed

Before, the tests were fine. The output was:

qemu: uncaught target signal 6 (Aborted) - exiting
qemu: uncaught target signal 6 (Aborted) - exiting
qemu: uncaught target signal 6 (Aborted) - exiting
abort01     1  PASS  :  Test passed

I've not tested with other targets but I fear that x86 should have same
trouble. From looking at the commits, I would say it's due to commit
edf8e2af1453ce56c72b2f25a745e3734177a05d. I didn't try to revert it so
it's like a shot in the dark.

Has someone an idea how to fix the problem ?

thanks,
Arnaud

Re: [Qemu-devel] linux-user and signal handling

[Ulrich Hecht]

On Thursday 18 June 2009, Arnaud Patard wrote:
> When doing some ltp syscall testing with arm-linux-user, some tests
> are failing with messages like that :
>
> qemu: uncaught target signal 6 (Aborted) - core dumped
>         Child did not return core bit set!
>           iteration 0, exit stat = 0x6
>         Core = 0, sig = 6, ex = 0
> abort01     1  FAIL  :  Test failed
[...]
> Has someone an idea how to fix the problem ?

Have you considered that the test might be broken? I tried it, and it 
fails in the same way on native AMD64 and i386...

CU
Uli

-- 
Heute ist
- Tag der Aussiedlung (in Ägypten)

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [Qemu-devel] linux-user and signal handling

[Arnaud Patard]

Ulrich Hecht <uli@suse.de> writes:

> On Thursday 18 June 2009, Arnaud Patard wrote:
>> When doing some ltp syscall testing with arm-linux-user, some tests
>> are failing with messages like that :
>>
>> qemu: uncaught target signal 6 (Aborted) - core dumped
>>         Child did not return core bit set!
>>           iteration 0, exit stat = 0x6
>>         Core = 0, sig = 6, ex = 0
>> abort01     1  FAIL  :  Test failed
> [...]
>> Has someone an idea how to fix the problem ?
>
> Have you considered that the test might be broken? I tried it, and it 
> fails in the same way on native AMD64 and i386...

well, of course. Before looking at the ltp test failures, the first
thing I'm doing is to check if the test is ok on the host without
qemu. It would be quite stupide to try to solve tests in qemu if they're
failing on the host system without qemu.

As regards the signal tests, they're ok here (it was on a x86 box) :

tag=abort01 stime=1245253207
cmdline="ulimit -c 1024;abort01"
contacts=""
analysis=exit
initiation_status="ok"
<<<test_output>>>
abort01     1  PASS  :  Test passed


Arnaud

Re: [Qemu-devel] linux-user and signal handling

[Ulrich Hecht]

On Thursday 18 June 2009, Arnaud Patard wrote:
> As regards the signal tests, they're ok here (it was on a x86 box) :

Works for me, too, now; the ulimit was missing. And the culprit indeed 
seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d; without it, it 
works in qemu-arm as well.

CU
Uli

-- 
Heute ist
- Tag der Aussiedlung (in Ägypten)

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [Qemu-devel] linux-user and signal handling

[Ulrich Hecht]

On Thursday 18 June 2009, Ulrich Hecht wrote:
> And the culprit indeed
> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d

Specifically, it's the part in force_sig() that sets the core limit to 0 
to prevent a core dump of qemu itself that causes the wrong core bit. 
Remove it, and the test passes. No idea how to fix that properly, 
though.

CU
Uli

-- 
Heute ist
- Tag der Aussiedlung (in Ägypten)

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [Qemu-devel] linux-user and signal handling

[Arnaud Patard]

Ulrich Hecht <uli@suse.de> writes:

> On Thursday 18 June 2009, Ulrich Hecht wrote:
>> And the culprit indeed
>> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d
>
> Specifically, it's the part in force_sig() that sets the core limit to 0 
> to prevent a core dump of qemu itself that causes the wrong core bit. 
> Remove it, and the test passes. No idea how to fix that properly, 
> though.

ok. That's interesting... Will look at that. Thanks a lot !

Arnaud

Re: [Qemu-devel] linux-user and signal handling

[Daniel Jacobowitz]

On Thu, Jun 18, 2009 at 06:27:02PM +0200, Arnaud Patard wrote:
> Ulrich Hecht <uli@suse.de> writes:
> 
> > On Thursday 18 June 2009, Ulrich Hecht wrote:
> >> And the culprit indeed
> >> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d
> >
> > Specifically, it's the part in force_sig() that sets the core limit to 0 
> > to prevent a core dump of qemu itself that causes the wrong core bit. 
> > Remove it, and the test passes. No idea how to fix that properly, 
> > though.
> 
> ok. That's interesting... Will look at that. Thanks a lot !

Sounds to me like what's happening is a feature... trading off a
host core dump for a target core dump.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] linux-user and signal handling

[Riku Voipio]

On Thu, Jun 18, 2009 at 01:14:39PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jun 18, 2009 at 06:27:02PM +0200, Arnaud Patard wrote:
> > Ulrich Hecht <uli@suse.de> writes:
> > 
> > > On Thursday 18 June 2009, Ulrich Hecht wrote:
> > >> And the culprit indeed
> > >> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d
> > >
> > > Specifically, it's the part in force_sig() that sets the core limit to 0 
> > > to prevent a core dump of qemu itself that causes the wrong core bit. 
> > > Remove it, and the test passes. No idea how to fix that properly, 
> > > though.
> > 
> > ok. That's interesting... Will look at that. Thanks a lot !
> 
> Sounds to me like what's happening is a feature... trading off a
> host core dump for a target core dump.

Or to be more specific, trading off a unneeded core dump of a qemu process
(since we got a core dump of the target process) to not having core bit set
in exit status.

If people depend on WCOREDUMP(), we can remove that bit of eliminating
the host process coredump.

Re: [Qemu-devel] linux-user and signal handling

[Arnaud Patard]

Riku Voipio <riku.voipio@iki.fi> writes:

> On Thu, Jun 18, 2009 at 01:14:39PM -0400, Daniel Jacobowitz wrote:
>> On Thu, Jun 18, 2009 at 06:27:02PM +0200, Arnaud Patard wrote:
>> > Ulrich Hecht <uli@suse.de> writes:
>> > 
>> > > On Thursday 18 June 2009, Ulrich Hecht wrote:
>> > >> And the culprit indeed
>> > >> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d
>> > >
>> > > Specifically, it's the part in force_sig() that sets the core limit to 0 
>> > > to prevent a core dump of qemu itself that causes the wrong core bit. 
>> > > Remove it, and the test passes. No idea how to fix that properly, 
>> > > though.
>> > 
>> > ok. That's interesting... Will look at that. Thanks a lot !
>> 
>> Sounds to me like what's happening is a feature... trading off a
>> host core dump for a target core dump.
>
> Or to be more specific, trading off a unneeded core dump of a qemu process
> (since we got a core dump of the target process) to not having core bit set
> in exit status.
>
> If people depend on WCOREDUMP(), we can remove that bit of eliminating
> the host process coredump.

I understand the idea is to get coredump for the target and not of the
host. What's worrying me is that it should be transparent to the target
and it's not the case.
It would be nice if this can be fixed. If this can't be done, maybe this
can be clearly documented that the core bit is corrupted by qemu and
stop worrying about that. Getting a bug-free emulation is very hard
after all :)


Arnaud

Re: [Qemu-devel] linux-user and signal handling

[Riku Voipio]

On Thu, Jun 18, 2009 at 09:40:24PM +0200, Arnaud Patard wrote:
> Riku Voipio <riku.voipio@iki.fi> writes:
> > Or to be more specific, trading off a unneeded core dump of a qemu process
> > (since we got a core dump of the target process) to not having core bit set
> > in exit status.

> > If people depend on WCOREDUMP(), we can remove that bit of eliminating
> > the host process coredump.

> I understand the idea is to get coredump for the target and not of the
> host. What's worrying me is that it should be transparent to the target
> and it's not the case.
> It would be nice if this can be fixed.

It can be fixed - like with the patch below. The question is which
people want it? I'm beginning to think we should go with the correctness
and live with the slighly annoying extra coredump.

>From ee2f075ebbfa35f11bcfffb813ed6288e536262b Mon Sep 17 00:00:00 2001
Message-Id: <ee2f075ebbfa35f11bcfffb813ed6288e536262b.1245398394.git.riku.voipio@iki.fi>
From: Riku Voipio <riku.voipio@iki.fi>
Date: Fri, 19 Jun 2009 10:49:57 +0300
Subject: [PATCH 5/5] linux-user: do not avoid dumping of qemu itself

Previously we disabled dumping of qemu itself if we already
created coredump of the target process. This broke the abort01
LTP test and any application that used WCOREDUMP to find out
the child process dumped core. Remove this feature.

Signed-off-by: Riku Voipio <riku.voipio@iki.fi>
---
 linux-user/signal.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 6a34171..e1b6458 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -383,12 +383,6 @@ static void QEMU_NORETURN force_sig(int sig)
             ((*ts->bprm->core_dump)(sig, thread_env) == 0);
     }
     if (core_dumped) {
-        /* we already dumped the core of target process, we don't want
-         * a coredump of qemu itself */
-        struct rlimit nodump;
-        getrlimit(RLIMIT_CORE, &nodump);
-        nodump.rlim_cur=0;
-        setrlimit(RLIMIT_CORE, &nodump);
         (void) fprintf(stderr, "qemu: uncaught target signal %d (%s) - %s\n",
             sig, strsignal(host_sig), "core dumped" );
     }
-- 
1.6.2.1