[PATCH 2/4] score: Add validation that no extensions are null.

Jennifer Averett Jennifer.Averett at OARcorp.com
Fri Apr 18 18:51:22 UTC 2014



> -----Original Message-----
> From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> Sent: Friday, April 18, 2014 1:49 PM
> To: Jennifer Averett
> Subject: Re: [PATCH 2/4] score: Add validation that no extensions are null.
> 
> On 04/18/2014 07:45 PM, Jennifer Averett wrote:
> > I don't have the stack trace, but Joel and I both saw a section that
> > it looked like a NULL could be called from, I see the section of code you are
> > referring to and that is not where we were at.   It was before the zero
> > of memory was added to the capture engine, so we may have tromped on
> > the code and been somewhere that is not the normal path.
> >
> > I can't reproduce what we were seeing.
> 
> You have seen a call of a random pointer slipped in through the incomplete
> initialized extensions table on the stack.
> 
> >
> > I'll remove the patches for the null extensions, but I think the
> > capture engine patch is still correct, with the exception that the
> > fatal extension can be NULL instead of an empty method.
> 
> Yes, but I would make the extensions table static const.  I think also that we
> need a proper thread terminate event, since terminate and delete are now
> different things.

I thought about adding a terminate event, but since the terminate is being 
triggered by a delete of self it seemed the delete event would be the better
option.  The application user shouldn't have to understand the internals
to  understand the output from the capture engine (imo).

> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.





More information about the devel mailing list