Re: [Qemu-devel] [PATCH RFC v3 1/7] Fix segmentation fault when qemu_signal_init fails

[Peter Xu]

On Thu, Sep 20, 2018 at 12:46:39PM +0800, Fei Li wrote:
> 
> 
> On 09/20/2018 11:28 AM, Peter Xu wrote:
> > On Wed, Sep 19, 2018 at 09:35:17PM +0800, Fei Li wrote:
> > > Currently, when qemu_signal_init() fails it only returns a non-zero
> > > value but without propagating any Error. But its callers need a
> > > non-null err when runs error_report_err(err), or else 0->msg occurs.
> > > 
> > > To avoid such segmentation fault, add a new Error parameter to make
> > > the call trace to propagate the err to the final caller.
> > > 
> > > This patch also adds the omitted error handling when creating signalfd
> > > pipe fails in qemu_signalfd_compat().
> > > 
> > > Signed-off-by: Fei Li <address@hidden>
> > Hi, Fei,
> > 
> > Please do s/comc/com/ in the CC list, then I can receive your
> > emails. :)
> So sorry for the misspelling, somehow an unanticipated "xx.com"c is sent. :(
> > 
> > Could you explain a bit how the segfault is triggered?  malloc() and
> > pipe() aren't something that will fault easily to me, so I would think
> > we just assert (especially it's in a very early phase of the process).
> > 
> > Thanks,
> This is actually triggered after the 7th patch is applied, when I do the
> test
> by hard coding the returning value of pthread_create() as EPERM or EINVAL.
> Considering there is already an "exit()“ if qemu_init_main_loop() fails, let
> us use this exit()?

I see.  For me, null-referencing is already a good debugging tool
itself which works just like assertions (then we see the stack clearly
enough when rare bad things happened), so I'll just leave these to the
other reviewers (I saw that Fam reviewed most of the series already).

Regards,

-- 
Peter Xu