6332 2014-05-14 21:21:26 +0000 bbclass handlers that handle MetadataEvent's clobber that event's 'data' member 2014-10-28 10:47:09 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.6 x86 Multiple RESOLVED FIXED Medium normal 1.7 1 dave.lerner alexandru.damian poky.bs.watcher poky.watcher --- --- Don't know oldest_to_newest 43345 0 1958 dave.lerner 2014-05-14 21:21:26 +0000 Created attachment 1958 a bbclass that is dispatched with MetadataEvent or all events As tested in daisy release. If the function bb.event.execute_handler() is called to run a registered event handler, and if the event is a MetadataEvent, then the event member variable 'data', is destroyed by execute_handler() which causes failures for other handlers registered for that event, such as the toaster event handlers. This happens when either - a bbclass invokes 'addhandler' without setting an event mask, and consequently gets all events, or - a bbclass adds the handler and sets the handler's event mask to MetadataEvent. To reproduce the case where a handler receiving all events clobbers the MetadataEvent.data member variable: 1) copy the attached file bug_event.bbclass into poky/meta/classes 2) run the init script source oe-init-build-env 3) append to conf/local.conf INHERIT += "bug_event" 4) start toaster which listens for metadata events source toaster start 5) generate some events bitbake quilt-native ... NOTE: bug_event: data was found in vars as dispatched by execute_handler ... The event handler reports that all MetadataEvents have the 'data' member variable, as shown by the above highlighted "NOTE: bug_event", only the "'data' in vars(e)" clause executes in the code below: python bug_event() { if isinstance(e, bb.event.MetadataEvent): if 'data' in vars(e): bb.note("bug_event: data was found in vars as dispatched by ... else: bb.note("bug_event: data was NOT found in vars as dispatched by. } 6) While the bug_event.bbclass reports that MetadataEvent.data existed, the toaster event handlers reports that the metadata events have lost the 'data' member variable: grep assert toaster_ui.log assert 'data' in vars(event) ... To reproduce the case where a handler receiving metadata events first clobbers the 'data' field for subsequent handlers 1) edit the poky/meta/classes/bug_event.bbclass to uncomment the eventmask line - #bug_events[eventmask] = "bb.event.MetadataEvent" + bug_events[eventmask] = "bb.event.MetadataEvent" 2) reset toaster and toaster logs source toaster stop ; rm toaster* ; source toaster start 3) generate some events bitbake quilt-native ... NOTE: bug_event: data was found in vars as dispatched by execute_handler ... 4) the toaster logs still assert MetadataEvent.data is missing: grep assert toaster_ui.log assert 'data' in vars(event) ... 43371 1 richard.purdie 2014-05-15 15:04:05 +0000 The data member is only available in certain events. If you look at the server event code, this is added for some classes of events, and not added for others. 43379 2 dave.lerner 2014-05-15 15:49:35 +0000 I don't understand your comment. Should MetadataEvent constructor not setup a 'data' member variable that is potentially destroyed by execute_handler if a bbclass registers for all events? The way execute_handler is written it assumes that _NO_ event has a 'data' member. 1) If a handler does not set an event mask, then the MetadataEvent will be dispatched to that handler via execute_handler 2) During the dispatch in execute_handler the MetadataEvent.data member is a) first overwritten, b) then deleted 3) When the MetadataEvent is then sent to the UI handler, the MetadataEvent.data field expected by the toaster handlers has been destroyed and toaster throws an assert. 43506 3 richard.purdie 2014-05-22 15:40:08 +0000 Basically, we *cannot* send the data store over serialization. This means that while we can have it available for class events, it cannot be passed over to the UI and therefore it will not be present in the events the UI sees. We don't want this to happen either, the data store is *huge* and it would be bad to try and serialize and transfer it repeatedly through something like xmlrpc. So any data store present in events gets killed off by bb.event.execute_handler(), this is by design and isn't something we can easily change. 43507 4 richard.purdie 2014-05-22 15:45:10 +0000 Sorry, Paul clarified this. The "data" namespace in events is reserved for the datastore. The MetadataEvent is going to need to use a different name. Assigning to Alex to resolve. 44564 5 alexandru.damian 2014-07-18 13:12:20 +0000 Patch sent to mailing lists. 46615 6 alexandru.damian 2014-10-28 10:47:09 +0000 Merged and Fixed. 1958 2014-05-14 21:21:26 +0000 2014-05-14 21:21:26 +0000 a bbclass that is dispatched with MetadataEvent or all events bug_event.bbclass application/octet-stream 644 dave.lerner CiMgUmVwcm9kdWNlciBmb3IgdGhlIGJ1ZyBpbiBiaXRiYWtlL2xpYi9iYi9ldmVudC5weSB0aGF0 IGRlbW9uc3RyYXRlcwojICh3aXRoIHRoZSBhc3NlcnRpb24gaGVscCBvZiBiaXRiYWtlL2xpYi9i Yi91aS9idWlsZGluZm9oZWxwZXIucHkpCiMgdGhhdCBhIGNsYXNzIGhhbmRsZXIgdGhhdCBoYW5k bGVzIGFsbCBldmVudHMgd2lsbCBkZXN0cm95CiMgTWV0YWRhdGFFdmVudC5kYXRhIGR1cmluZyB0 aGUgZGlzcGF0Y2ggaW4gYmIuZXZlbnQuZXhlY3V0ZV9oYW5kbGVyKCkuCgpweXRob24gYnVnX2V2 ZW50KCkgewogICAgaWYgaXNpbnN0YW5jZShlLCBiYi5ldmVudC5NZXRhZGF0YUV2ZW50KToKICAg ICAgICBpZiAnZGF0YScgaW4gdmFycyhlKToKICAgICAgICAgICAgYmIubm90ZSgiYnVnX2V2ZW50 OiBkYXRhIHdhcyBmb3VuZCBpbiB2YXJzIGFzIGRpc3BhdGNoZWQgYnkgZXhlY3V0ZV9oYW5kbGVy IikKICAgICAgICBlbHNlOgogICAgICAgICAgICBiYi5ub3RlKCJidWdfZXZlbnQ6IGRhdGEgd2Fz IE5PVCBmb3VuZCBpbiB2YXJzIGFzIGRpc3BhdGNoZWQgYnkgZXhlY3V0ZV9oYW5kbGVyIikKfQog ICAgCmFkZGhhbmRsZXIgYnVnX2V2ZW50CiNidWdfZXZlbnRbZXZlbnRtYXNrXSA9ICJiYi5ldmVu dC5NZXRhZGF0YUV2ZW50Igo=