On Mon, Nov 26, 2012 at 02:22:58PM +0100, Stefan Hajnoczi wrote:
> On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber <email address hidden> wrote:
> > Am 26.11.2012 13:10, schrieb Stefan Hajnoczi:
> >> visit_type_size() requires either visitor->type_size() or
> >> visitor_uint64() to be implemented, otherwise a NULL function pointer is
> >> invoked.
> >>
> >> It is possible to trigger this crash as follows:
> >>
> >>   $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \
> >>                        -device virtio-blk-pci,netdev=netdev0
> >>
> >> The 'sndbuf' option has type "size".
> >>
> >> Signed-off-by: Stefan Hajnoczi <email address hidden>
> >> ---
> >> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3.
> >
> > Reviewed-by: Andreas Färber <email address hidden>
> >
> > Did you check whether any other types were unhandled?
> 
> The visitors do not handle all types.  Only the opts visitor and now
> the dealloc visitor handle ->type_size().
> 
> This will not cause a problem yet because only the netdev options
> include fields with the 'size' type.  That code path is now covered.
> 
> In the longer term we should clean up the int, number, uint64, size
> type proliferation and handle them consistently.

Dealloc visitor is somewhat of a special case, as it only cares about
the underlying C type and not about the visitor-specific representation.
In the case of generated types like these, it only needs to match the
type that QAPI generates (uint64_t in the case of type_size).

For input/output visitors, new types should either have a compatible
fallback, or abort if there's no compatible fallback and we attempt to
use a visitor that doesn't support the type. AFAIK we don't have one
that falls into the latter category atm (there is one in the QIDL series
for native C arrays, which has no generic fallback and will abort in
cases where we use a visitor that doesn't implement that type
explicitly).

Dealloc shouldn't use compatibility fallbacks though, which is probably
something we need to clean up. It should have explicit implementations
for all types we introduce, and those implementations should match the
type use for QAPI-generated types.

> 
> > Should a comment be added somewhere along the lines of "If you add a
> > hook here you also need to implement one there" to avoid such
> > inconsistency for the future?
> 
> There is no single point like register_visitor() where we could check
> that callbacks are set up.  That would have been a nice way to prevent
> incomplete visitors.
> 
> The issue is that qapi/qapi-visit-core.h says type_uint64 and
> type_size may be NULL, but it documents that visit_type_size() falls
> back to type_uint64() if type_size() is NULL.  The case we hit was
> that type_uint64() is also NULL.  Should it fall back to type_int()
> (int64_t)?

I hit this issue implementing a test case for QIDL that introduces
the usage of type_size() for QmpOutputVisitor. The problem is that it
references ->type_uint64() directly instead of using visit_type_uint64()
which has the fallback handling (->type_int()) for visitors that don't
have a specific implementation for type_uint64.

I have a patch in the QIDL series that does this, and this would also fix the
issue you're hitting with the dealloc visitor, but as noted above I
think relying on fallbacks for the dealloc visitor is the wrong
approach, so I think we should treat these as 2 seperate issues and take
your patch for 1.3. The error case I hit isn't reachable in 1.3 atm so I
think that should be sufficient for now.

> 
> Stefan
>