[interfacekit] Re: Broken BMessage

Ingo Weinhold wrote:

On Wed, 18 Aug 2004, Erik Jaesler wrote:
Come to think of it, it might be that the Add/Find*() methods are perfectly bug-free and that only Flatten/Unflatten() screws up the internal data structure.

I wouldn't be surprized. As it is, Flatten() and Unflatten() are precisely where all my "nice" abstractions break down. Strings and other variable-length "buffer"-style data are largely responsible for that and the resulting multitude of policy classes. IIRC, there were two simple policy classes before I had to deal with that. =\

The code is in the repository. It's the unit tests for BAppFileInfo, BNodeInfo, BMimeType -- each test crashs at some point (all require a running obos_registrar). I haven't checked the App Kit tests that should also be concerned (BMessenger, BApplication), but as Jack says, he experienced crashes in the BApplication tests, too.

I'm not sure to what degree the Storage Kit unit tests run with the libopenbeos built from the sources currently in CVS, though. My local copy is heavily modified, but I can't check it in yet, because it would break the libroot built. If the tests don't run to the point where the BMessage related crashes occur, I can try and analyze the exact situation under which the crashes occur and add a respective BMessage unit test.

I will take a look at the tests. It would be good to have a unit test to cover this situation anyway, and you may be able to put one together faster than I

BTW, my template code is not *evil*, merely Very Obnoxious -- it's a matter of intent. ;)

I didn't mean `evil' in the negative sense. ;-) They just defy quick analysis by an uninitiated, as everything is delegated to policies. The simple debugger is not happy either; it doesn't even manage to print the full symbol name of the crashing function.

It is less than intuitive, no doubt there, although I was pleasantly surprized last night to find that even after all this time (I'd guess it's been about a year), the code still makes sense to me. I will try to fix it as-is so as to get you up and running ASAP.

I've also started sketching out a C API for managing BMessage's data as an always-flattened buffer, a la Dano. I've contemplating this approach for some time, mainly with the idea in mind of having it available for use in the kernel. At this point, though it would be less 133t (as the young kids like to say ;) than the existing template-based code, it would probably be easier to understand and maintain. If only because the debugger would be happier.

Anyway, bug fix first, new API second.

I apologize for leaving BMessage lying there half-baked. I very much wish my time situation was more allowing of Haiku work. =(

Such is (real) life. :-/

Indeed. It seems one can either have lots of time to hack Haiku (Holy Haiku hackers, Batman!) and nothing to eat, or lots to eat and no time to hack. I guess it's mphipps turn to know all about that right now. =P

e



Other related posts: